I'd like to again raise what I think is the 5th option on that list...
don't even bother :)
With the caveat that I haven't even entirely convinced *myself* its the
right answer, maybe this is the right time for a clean break where
compatibility isn't a concern.
I think I personally would prefer seeing everyones' efforts go towards
making the merger a success in terms of producing something that is
truly new and better, rather than trying to drag along what at that
point would be legacy support.
I made this comment yesterday, or maybe earlier today, I forget, that
1.x isn't going anywhere, and there are people willing to support it,
and that likely won't change any time soon. I personally can't see many
shops wanting to take a 1.x app and switch to Ti, justified by the
age-old adage "if it ain't broke, don't fix it".
Paraphrasing Ted (as I recall him saying), as long as *skills* largely
transfer, that's what counts.
If it was me, I'd first get a read on things to be sure everyone thinks
compatibility is truly worth whatever effort it might be, whether a
little or a lot of effort. If everyone does agrees its important,
*then* move ahead to how to do it.
Frank
Don Brown wrote:
I'd classify all those goals as those of approach 1, which is building
1.x support right in Ti. What I'm coming to the conclusion of is that
it would be a lot of work, be prone to surprise errors, and ultimately
futile. If my 1.x app is running fine, what would I gain by trying to
run it on a platform (Ti) which is buggy and where my fancy Struts
extensions (custom RequestProcessor, tricks using internal Struts APIs,
etc) won't work or only work sometimes.
My approach #2, to include 1.x jars and develop co-existing tools, lets
someone run a 1.x app "on" Struts Ti completely unchanged and with 100%
functionality, 1.x quirks and all. I think a user would mainly be
interested in that, and perhaps building new segments with Ti as the
opportunity arose.
But perhaps that is a faulty assumption. What do the rest of you think?
Don
Laurie Harper wrote:
<snip />
I have to ask if the goal behind 1 through 3 is the right goal... In
other words, should the goal be
1 - allow a Struts 1.x app to run unchanged on Ti
2 - allow a Struts 1.x app to run unchanged on Ti, w/ some caveats
3 - allow a Struts 1.x app to run on Ti, with only minor changes
4 - allow a Struts 1.x app to run on Ti, with a well defined set of
migration changes, possibly supported by automated tools
I thought there was a general leaning towards something more like 4,
with a corresponding minimization of code in Ti solely for the sake of
1.x compatibility. IMHO the right balance would be somewhere between 3
and 4; 1 and 2 impose a higher burden on Ti than should be expected or
required of a 'Struts 2.0'.
I know, that totally subverts the discussion, but I think deciding
this issue informs that discussion. Unless I missed something that
answers this issue already :-)
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
