Go ahead with it, thanks for volunteering. musachy
On Mon, Aug 10, 2009 at 8:30 AM, Rene Gielen<rgie...@apache.org> wrote: > 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 > > -- "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
