Speaking for myself, yes. On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Ted, I read what you wrote here with interest. I consider myself a > champion of backwards compatibility... in fact, within the past month I > recall being involved in a discussion thread here where I seemed to be > the only one saying backwards compatibility should not be broken, within > the context of that discussion (which, to be honest, I do not recall :) > ). I completely agree that it is an important consideration always. > > What I infer from what you wrote, and please correct me if the inference > is not accurate, is that the milestone of breaking things out into > subprojects could in essence serve to open the floodgates a bit... > meaning, maybe the committers will be more willing to entertain some > ideas that they may have previously passed on once that reorganization > is complete and "in the wild" because it will theoretically be easier to > do them then. Is that a fair assessment? > > If so, I for one look forward to the 1.3 release even more than I did > before :) > > Frank > > Ted Husted wrote: > > On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > >>Over the past few months there have been a number of people who have > >>attempted to evolve Struts to "catch up" in some ways with what other > >>frameworks are doing. They have been turned away, sometimes for > >>obviously legitimate reasons, sometimes for more debatable ones. > > > > > > Usually, the problem has been retaining backward compatibility. When a > > suggestion breaks backward compatibility, we tend to pass, at least > > until we can setup a deprecate/ remove/ release cycle. Since this > > cycle can take a year or more, some people drift away before we can > > implement a suggestion. > > > > Some suggestions have been out of scope, mainly for the taglibs. Along > > the way we decided that the original taglibs should stick to the HTML > > 4.1 specification. Some taglib suggestions are non-starters because of > > the product's scope. > > > > The big fix for both of these problems, and several others, is to > > subdivide the one-size-must-fit-all Struts distribution into > > subprojects. If a suggestion is not backwardly compatible, then > > perhaps we can make it an optional component in the Extras subproject. > > If a taglib is not HTML 4.1 compliant, then maybe we can start another > > taglib subproject. > > > > But, until last month, we simply didn't have the infrastructure to > > even consider such things. > > > > Another problem is being sure that there be someone around to maintain > > the code. We like to see broad enough support for any suggestion to > > ensure that there will be at least three people around who will > > support the code. It doesn't matter if comes from a developer or a > > committer. A lot of suggestions from committers die on the vine > > because too few people seem interested. > > > > Many folks don't realize that extensions we now take for granted, like > > Validator and Tiles, were being used in production applications for > > *years* before we added them to the distribution. (I used both myself > > in April 2001, before Struts 1.0 final.) > > > > In the same light, I expect we will see an Ajax subproject for Apache > > Struts one day. But before that happens, we'd like to see broad > > support for Ajax among Struts users. Then, we can be sure there will > > be committers around to support the subproject later. > > > > As it stands, we are just now completing tasks we planned *18 months* > > ago. But, we are completing them, slow and steady. > > > > In fact, I remember Don Brown making the first "subproject > > reorganization" commits at ApacheCon 2004 last November. Martin and I > > were sitting at a table with him at the Hackathon, jovially giving Don > > verbal +1s. :) > > > > Ten months later, we're finally at the point where we can build and > > distribute the original Struts subprojects, along with the new kids on > > the block, Flow, Scripting, and Shale. > > > > > >>Everyone seems to want to go off and create something entirely new when > >>I haven't seen a single good, concrete reason why Struts as it exists > >>today can't be evolved. Why? > > > > > > It *is* being evolved. It's just that evolution takes time. > > Personally, I still fully intend to walk down the Struts Classic > > Roadmap that we posted over a year ago. We're just now hitting the > > first milestone: subprojects. We hit this one, and we'll hit the > > others too. > > > > * http://struts.apache.org/roadmap.html > > > > Meanwhile, exploring alternatives like Ti can be good for Struts > > Classic too. Like as not, there will be techniques used in Ti that we > > can retrofit to Struts Classic. And, perhaps, one day, they might even > > evolve into the same product. Or not. At this point, Ti is still > > hypotethical. > > > > > >>Many of the things that people claim to want in a modern framework I > >>have either myself done or seen done with the current Struts codebase. > >>Things like components that remember and render their own state ala JSF, > >>a simple managed bean facility (IoC), built-in AJAX support, something > >>akin to a prerender facility, the work of Michael Jouravlev, all of > >>these things have been done in Struts, so clearly it is not a case of > >>Struts not being expandable or "fixable". Why is there so much seeming > >>resistance to doing this I wonder? > > > > > > It's not resistance, it's as you say: If we want to, we can already do > > all of this now in our own applications. I expect that many of us are. > > But, going the extra yard and making what we do for ourselves > > available to everyone is a lot of work. We're doing the work, but it's > > on a time available basis, and most of us have very little time > > available. Unlike some open source projects, we don't have any > > committers who are paid to work on Struts during company time. > > > > Because committers tend to have busy professional lives, we try to > > bring on new committers whenever we can. Last month, we brought on > > Wendy Smoak, who has been a godsend. With help from James, She's > > propelled the Mavenized web sites forward, and we can see the light at > > the end of the tunnel. > > > > Meanwhlile, after adding the "extends" feature, our other new hand, > > Hubert, cleaned up the stale deprecations, so we can continue to > > steadily evolve the codebase. Now, it's left to me to finish > > refactoring the documentation, and push Struts Classic 1.3.0 out the > > door. It won't be a final release, but it will tap the keg. > > > > Once we have a 1.3.0 distribution out for review, I plan to review the > > 22 enhancement tickets with patches, and apply as many as we can. > > > > If someone wanted to preview those patches, and post a summary to > > dev@, that would be helpful. There are prefab bugzilla query links on > > the RoadMap page. > > > > * http://struts.apache.org/roadmap.html#Bugzilla > > > > There's a wiki page already setup for 1.3.1, and we can start making > > notes on what to do about these other outstanding contributions. > > > > * http://wiki.apache.org/struts/StrutsClassicRelease131 > > > > -Ted. > > > > --------------------------------------------------------------------- > > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- HTH, Ted. http://www.husted.com/poe/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
