Still no objections so far. I would volunteer to help with IP clearance Musachy Barroso schrieb: > 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 >> >> > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
