On Sat, 1 Mar 2003, John Yu wrote:
> Date: Sat, 01 Mar 2003 16:34:07 +0800 > From: John Yu <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: Re: Short term plans > > At 11:46 am 01-03-03, you wrote: > >JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 > >and JSP 1.2, so they are not even an option for a very significant portion > >of the Struts user community. Thus, it would be irresponsible to abandon > >our focus on ensuring the quality of the Struts tag libraries -- and this > >would be true even if Struts was a commercial product instead of an open > >source package. > > With respect (too :-), what criteria should/would the (developer) community > use to strike a balance, both ensuring the quality and relevance of Struts > taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 > dependent)? > > For instance, in a recent feature request: > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 > > As David, the recently crowned MVC (what an acronym), pointed out the > requested feature for <bean:message> is already available in JSTL > <fmt:message>. Is there an easy litmus test for Struts users to guestimate > if an enhancement is worthwhile requesting? > Good question. I think there are multiple perspectives for asking for enhancements, all of them valid. Some examples: * "I need it" -- This particular feature would help me out right now, without disrupting my entire app by forcing me to upgrade to the "latest and greatest." * "Lots of people need it" -- This particular feature would be generally useful to lots of people using an existing version of Struts (think about how many add-on libraries and tags work fine with 1.0.2 based apps). * "I want to work on it" -- If we are limited by the number of developers working on Struts and we want those folks working on the future stuff, nothing stops us from adding some more developers that want to continue to enhance the existing tags. NOTE -- this perspective is the most critical for actually getting anything done :-). There's nothing wrong with people operating from any and all of these perspectives simultaneously. In all cases, of course, patches that actually *implement* the new feature (rather than just an enhancement request asking for it) is a lot more likely to get the thing actually done (modulo timing delays when we're trying to get a release out the door). And, if you do that enough times, you're likely to find yourself operating from the third perspective and welcomed as an additional Struts developer -- and people who want to do that would be welcomed. A fourth perspective that is also valid is to be future looking: "what do we want a future Struts to look like" without being as much concerned about existing users with their day-to-day real life problems. We haven't spent a lot of time (yet) talking about that on the STRUTS-DEV list -- at least partly because I've been afraid we would dive into those (fun) discussions and sort of ignore the fact that 1.1 isn't out the door yet :-). It's certainly time to start articulating our thoughts and desires on this, so we can come to agreement on a coherent roadmap. On the particular issue of the existing Struts tags, at this point I can only state my own interests and plans: * I'm interested in enabling the convenient use of JSTL and JavaServer Faces technologies with an existing and future Struts controller environment. I'm not *personally* going to focus on maintaining and enhancing the existing tag libraries, but it would be ridiculous and counter-productive to suggest that others who want to work on them should not -- I apologize if *I* have ever implied that in my previous comments. * I'm interested in separating the core controller part of Struts (which I personally consider to be the most important part) from the current somewhat tight integration with the JSP tags as the view layer. Organizationally, this might well mean independent releases of the core and appropriate view technology libraries (and perhaps its even time to think about becoming a top-level Apache project like Ant, Avalon, and a few others have done -- but that's for a separate mail thread) * I'm interested in decoupling the controller part of Struts from its current heavy reliance on the Servlet APIs. Among other things, that would enable easy use of Struts in portal servers that will support the emerging portlet API (JSR-168). You've also heard Ted and others talk about the need for a good controller paradigm in the business tier as well as the view tier. We know how to build such a thing :-). * I'm interested in continuing to support Struts users that cannot drop everything and instantly move to the latest and greatest API versions. For example, it's still way way way too early to think about Struts 1.2 being based on Servlet 2.4 and JSP 2.0 (the currently emerging standards that are part of J2EE 1.4). I would contend that making Struts 1.2 dependent on Servlet 2.3 and JSP 1.2 might still be premature as well -- much as I would like it (from both a Struts perspective and a Sun perspective :-), the whole world just isn't running on J2EE 1.3 yet. Now, I'm certainly game for add-on packages that require the newer spec versions (like struts-el and the upcoming Faces integration), to encourage people to move -- but forcing them to switch (or, worse, cavalierly leaving them behind) is not good for customer relationships. <Side note to Vic -- this is the same reason why making Tomcat 5 dependent on JDK 1.4 instead of 1.2, as you've suggested there, is premature at this point IMHO.> My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a "release often" model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. At the same time, Struts 2.0 discussions should commence, and some early milestone work will emerge in parallel. The two development cycles need to overlap (to avoid a huge gap between 1.2.x and 2.0.x later on), and that's all fine -- it's the natural order of software to have overlapping version trains. And the 1.2 train will certainly include continued work on the existing Struts tag libraries, to the extent that people want to work on them. All of this, of course, is *my* preferences and desires. The nice thing about open source is that you're not stuck being limited by your own (sometimes tunnel) vision and available energy. The developer and user communities that have grown up around Struts show all the signs of a group that can come to consensus around a future road map, and work on various aspects of it in parallel, with the usual synergies you get when more than one smart person works on a problem. I'm looking forward to this future. > regards, > > -- > John Yu Scioworks Technologies > e: [EMAIL PROTECTED] w: +(65) 6873 5989 > w: http://www.scioworks.com m: +(65) 9782 9610 > Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
