Just to recap on this (no, I won't let this go stale ;) ), we have a consensus on using JQuery as the underlying framework for the ajax tags, and we agree that we could use this project. Is there any objection against starting the IP clearance process, any volunteers to help with this? (assuming there are no objections)
musachy On Wed, Jul 29, 2009 at 4:52 AM, Rene Gielen<gie...@it-neering.net> wrote: > First and foremost, I totally agree that we should avoid to have a > driven-by-excitement attitude on this topic, and develop a reasonable > consensus and plan. See further comments inline > > Martin Cooper schrieb: >> >> I'm here, and I've been following along. I just haven't had time to >> consolidate my thoughts until now. >> >> First of all, I hope everyone recognises that it's by no means my call; >> it's >> the team's call. >> >> The subject of Ajax tags in Struts 2 has been hotly discussed over a >> period >> of years. At different points in time, different bases for such tags have >> been the hot favourite, from custom code through Dojo to jQuery, with a >> few >> other stops in between. Some of the work has happened here and some has >> happened elsewhere. >> > > As far as I recall, the main discussions were: > > - as we have a Dojo 0.4 integration, can we migrate to 0.9 (at that time)? > Turned out to be that that would be more sort of a rewrite than a migration, > and nobody was stepping up to do this - not only for limited resources, but > also for technical doubts about the framework regarding it's API stability, > performance, programming model and adoption rate. > > - Could AJAX framework x be integrated? Every once in a while, this question > arose, and the most mentioned candidates for x were Prototype and jQuery > AFAIR > > - Closely related to the former question: If we add support for another n > AJAX frameworks, would we want to to design an abstract API to have the same > tags with an easy to switch implementation done with user's AJAX framwork of > choice? Although I once was a firm supporter of this idea, it turned out to > be hard to realise because the frameworks extremely differ in their > architectures and programming models. > IMO, there are basically two feasible ways to go: define a base tag api and > components, that every AJAX tags plugin is required to implement (along with > consistent core attribute naming and behaviour). On top of that, allow the > plugins to have their special feature stuff - similar to JSF in that case. > The other way to go could be: If the user decides to go with strut2-[AJAX > framework x]-plugin, he will most likely not switch to framework y during > the lifetime of his project, so just develop plugin x and y independently to > fit best the underlying framework's architecture and capabilities. > > Again, that's what I recall from the last years - anybody feel free to chime > in and add, correct or discuss. > >> From my perspective, it is critical, in adopting any set of Ajax tags as a >> baked-in part of Struts, that we, as a team, are fully convinced (a) that >> the underlying toolkit is not just the flavour of the month and will last >> for years to come, and (b) that we have a sufficient body of developers >> committed to making it work today and keeping it working years from now. >> And >> I do mean years here. Certainly the world will change, and the world of >> highly interactive web apps will change. But think about this: Struts 1 >> was >> first released 9 (nine) years ago, and many thousands of web apps that >> were >> built on it are still running, and being maintained, today. I'm sure we >> would all like to have that level of success, and longevity, with Struts >> 2. >> It takes commitment, though. >> > > Totally agree. As for the flavour of the month aspect, I would add that > jQuery should IMO be considered to have overcome this stage. > >> I do take issue with a few statements that have been made in this thread >> about Ajax toolkits. Rene said that we can consider Dojo "the biggest >> loser". Can we really consider a toolkit that has seen corporate adoption >> from the likes of IBM, Sun, AOL, Google, Nexaweb, and numerous others, >> "the >> biggest loser"? Some people here may not like to work with it, but Dojo is >> one of the biggest success stories in the Ajax world. That's not to say >> that >> jQuery has not had its successes - and, as Wes points out, has seen >> adoption >> by Microsoft - but jQuery is still a long way from "the" Ajax framework >> that >> Rene asserts. >> > > OK, let me clarify here. I regard Dojo as the biggest loser not because it's > generally bad or not adopted. It's because of the mismatch between claims > and reality here. If you look at the Dojo supporting committee, it looks > like a who is who dictionary. Just to mention a few: IBM, Sun, BEA, Redhat > or Zend. But what was the outcome? One would expect that with such a huge > supporting group, the progress should be fast and the documentation should > be good. Actually, the development towards something regarded as stable took > ages, and the documentation was extremely poor (which may have changes > nowadays). The line ending in 0.4 line was around for one or two years > AFAIR, when it was decided that the framework has to undergo a major > refactoring towards the 0.9 line, which was not compatible with 0.4 any > more. Many early adopters were facing the fact that moving to 0.9 would be > as painful as reevaluating the other frameworks now around and possibly > switch to one of these, and a lot of them did so. Although Dojo was one of > the first movers to provide an AJAX framwork, they turned out to be one of > the latest to declare a stable release. > > I totally respect that having an 0.x release usually indicates that the API > is likely to change, but I would expect to have a reasonable timeframe then > for early adopters to get a maintainable production quality release - > especially for a project not only with this many contributors, but also with > contributors getting paid for their work as their employer sees the > framework as a strategic product. Actually the development of Dojo started > in 2004-2005, and the 1.0 release was in late 2007. By this time, jQuery 1.2 > and Prototype 1.5.1 were already released. Given the claim and the > impressive supporter list of Dojo, this is what I call being a big loser. > > As for adoption, although far from representative, here are two interesting > links comparing a couple of JS frameworks: > > http://royal.pingdom.com/2008/06/11/javascript-framework-usage-among-top-websites/ > http://www.kylehayes.info/2009/03/29/survey-results-javascript-frameworks/ > > For me it looks like, in spite of the good intentions of an impressive > committee, the users have voted with their feet. Dojo's actual relevance is > quite poor, and that's the second reason why I call it a loser (again, > compared to it's claims). IMO Dojo is a great example that > design-by-committee can have it's downsides... > >> That said, the above is not an argument against the adoption of jQuery as >> the basis for Struts 2 Ajax tags. It's merely my attempt to bring us down >> to >> earth a little bit in our enthusiasm to jump on jQuery and ditch Dojo. >> Each >> has its merits, as do other alternatives. >> > > As for ditching Dojo: Actually, we already did when we put it into > maintainance mode. In respect to what state Dojo has now, I would not say we > really do have a Dojo plugin - we do have an AJAX-features tags plugin based > on an early Dojo version. Of course we need to keep it for backwards > compatibility. > >> So, assuming the general concensus is to move forward with integration of >> Johannes' tags, what are the next steps? >> >> 1) Musachy hit the nail on the head when he said "I would like for us to >> define some strategy for this". It's crucial that we define, up front, >> where >> we want to go with this. What should the Ajax tags include? What should >> they >> specifically _not_ include, which is at least as important? Do we still >> believe that what we want is a set of simple tags and nothing more? If >> not, >> why not? How much coupling - that is, loose or tight - do we want to live >> with? It would be great to see some (more) discussion of this kind of >> thing >> up front, and perhaps the concensus documented on the wiki for all to see >> (and abide by). >> >> 2) Once we've agreed on the major points from #1 above, we can take a >> clear-headed look at what Johannes has done and assess how well it meets >> those needs. What would need to be added? What should be removed, to keep >> it >> streamlined to our objectives? We should be sure that we're not jumping on >> the "cool" factor, and have something that forms the basis for our needs. >> > > Agree, and great to see that Musachy already set up a Wiki page for that. > But we should also incorporate and respect the S2 users' view the best way > possible. Now that Johannes' plugin is out, it will get hard to keep things > "under control", given the assumption that we will have a lot of S2 users > starting to adopt the plugin very soon. Our timeframe to canalize this is > IMO quite short. What I suggest is that, given that we would have a > consensus to incorporate a first class citizen plugin based on Johannes work > backed by our first impressions of the plugins' code and functional quality, > we should move it to sandbox even before we start major architectural > discussion and detailed planning. That would have the following, IMO > important, effects: > > - provide an early and clean integration point from a build management / > Maven perspective for early adopters > > - we would clearly signal that although the original work is declared 1.0, > users should not directly use it but rather use the sandbox project, with > clearly stating that they have to see themselves as early adopters of a > moving target > > - incorporate early adopters' feedback soon and canalized via the Struts > lists > > Nevertheless, this would assume that we manage to find a solution for > Martin's point 4) below. > > A side note regarding architecture: We should have a close look to the new > JSF 2.0 versioned resource management system which was especially designed > to integrate cleanly separated versions of the JS frameworks the JSF > implementors want to provide and to overcome problems in managed > environments such as Portals. We had big troubles with Dojo in that aspect, > and we should try to do better for the plugins to come. > >> 3) If we're going to bring Johannes' code into Struts itself, we need an >> iCLA, and personally I would prefer to see us use the IP Clearance process >> to make sure we're all squared away. Johannes' iCLA is on file already. >> The >> IP Clearance process is intended to be straightforward and quick, so it >> should not be an issue. >> >> 4) Musachy does raise an excellent question regarding commit rights and >> the >> sandbox. We have not hit this exact case before. Obviously we'll need to >> figure this one out. >> >> One final point: I recognise and understand the enthusiasm that's behind >> the >> "let's get it in here now!" sentiment, but really, we're not in a huge big >> hurry. Let's take the time we need to think through where we want to take >> this, before we head of down the road with it. A week or two here or there >> won't make any difference in the long run, but poor decisions will. >> > [snip] > > A week or two (or even three or four :-) ) is fine, but we should have in > mind that things can get out of our hands soon if the progress is lazier > than that. That being said, I totally agree with Martin's point here. > > - Rene > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
