Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Sam Ruby wrote: Martin van den Bemt wrote: How do you fit in / are going to fit in with http://www.eclipse.org/proposals/atf/ ? Zimbra is mentioned there. If you look closely, that proposal closely matches the diffs between the first draft and second draft of the AJAX Toolkit Proposal that was presented here. It is indeed a diff :) In short, the ASF was originally the first choice for where that code would continue to be developed. Based on the feedback received here and elsewhere, an executive decision was made, and as far as I know, the proposal is receiving a warm welcome at Eclipse. Which (at least in my opinion) has a better natural home at Eclipse. Especially with looks like generic tooling for Ajax toolkits (not saying it wouldn't do well at Apache though) I would suggest that those who want there to be one or more AJAX projects at the ASF take a moment and consider how to make constructive suggestions on how to make that happen. My mail wasn't meant to be destructive at all (at least if that is the impression you got). It would be nice to have more Ajax projects onboard though, but it is still up to those projects to decide if they want to move here or not. A bit more constructive wouldn't hurt though, we could unintentionally give the wrong signal to the outside world and this way prevent interested project from taking the step to Apache. Although on the other side it is better to have a discussion than complete silence :) And, should you feel so inclined, feel free to update the Kabuki proposal: http://wiki.apache.org/incubator/KabukiProposal Adjusted and also added the Kabuki proposal to the main incubator wiki page. If you want to chose different words for what I have written, please go ahead :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] AJAX Toolkit Proposal - Updated
Sam Ruby wrote: To be honest, I would rather those points be placed on an general incubator page as they apply to every proposal. Jean just took care of that, using your wording. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Noel J. Bergman wrote: Sam Ruby wrote: To be honest, I would rather those points be placed on an general incubator page as they apply to every proposal. Jean just took care of that, using your wording. :-) actually, thanks to Gavin's patch posted to INCUBATOR-13 (Thanks, Gavin!) -jean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Noel J. Bergman wrote: Sam Ruby wrote: To be honest, I would rather those points be placed on an general incubator page as they apply to every proposal. Jean just took care of that, using your wording. :-) I take no credit for that wording. I simply took *your* wording, and de-AJAXed it. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
How do you fit in / are going to fit in with http://www.eclipse.org/proposals/atf/ ? Zimbra is mentioned there. Mvgr, Martin Andrew Clark wrote: I have made a few modifications to the Ajax proposal Wiki page[1] in an attempt to resolve a few of the issues people have raised. The changes include: * Changed name to Kabuki * Added text to clarify the scope of the project Please let me know if there are any other issues that should be addressed by changes to the proposal text. Please note that the name change requires you to update any bookmarks you may already have for the old link. [1] http://wiki.apache.org/incubator/KabukiProposal - Original Message - From: Sam Ruby [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Tuesday, January 17, 2006 1:03:59 PM Subject: Re: [VOTE] AJAX Toolkit Proposal - Updated Andrew Clark wrote: Sam Ruby wrote: And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Andy, any preference? I don't have any particular preference in regards to the name. If people have a problem with AjaxTk being too broad, then any other name will do. I have a natural preference towards Japanese names, though, so I'll suggest Kabuki. :) That does seem like a very fitting name. Can I ask you to create the following page, and fold in your answer to Justin's concern? http://wiki.apache.org/incubator/KabukiProposal - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Martin van den Bemt wrote: How do you fit in / are going to fit in with http://www.eclipse.org/proposals/atf/ ? Zimbra is mentioned there. If you look closely, that proposal closely matches the diffs between the first draft and second draft of the AJAX Toolkit Proposal that was presented here. In short, the ASF was originally the first choice for where that code would continue to be developed. Based on the feedback received here and elsewhere, an executive decision was made, and as far as I know, the proposal is receiving a warm welcome at Eclipse. I would suggest that those who want there to be one or more AJAX projects at the ASF take a moment and consider how to make constructive suggestions on how to make that happen. And, should you feel so inclined, feel free to update the Kabuki proposal: http://wiki.apache.org/incubator/KabukiProposal - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
When I originally kicked off this vote, I specified today, midnight, as the 72-hour-and-then-some deadline. Since then the proposal got a substantial revision (in particular, a new name) on Tuesday afternoon, so extending this a few hours to 4PM PST seems in order. I believe that the current wiki page: http://wiki.apache.org/incubator/KabukiProposal addresses all if not most of the concerns expressed by Roy, Leo, and Erik, each of which had expressed an explicit -1, and would be very interested to hear if this is in fact the case or if there are second order concerns that need to be brought forward. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
On Thu, Jan 19, 2006 at 10:59:57AM -0500, Sam Ruby wrote: When I originally kicked off this vote, I specified today, midnight, as the 72-hour-and-then-some deadline. Since then the proposal got a substantial revision (in particular, a new name) on Tuesday afternoon, so extending this a few hours to 4PM PST seems in order. I think cancelling this vote and its associated mile-long thread, compiling a list of the issues raised over the last few weeks, stepping through that list, addressing it (or attempting to convince us they'll be sufficiently addressed later), then re-starting the vote is in order. No, I'm not volunteering. I believe that the current wiki page: http://wiki.apache.org/incubator/KabukiProposal addresses all if not most of the concerns expressed by Roy, Leo, and Erik, each of which had expressed an explicit -1, and would be very interested to hear if this is in fact the case or if there are second order concerns that need to be brought forward. I'm not going to lift a -1 that probably caused a lot of people to not vote (esp. since there were several) so that a vote can end in a few more hours. That just sucks and if that's really you're goal here you have me very confused -- you don't want the perception that this thing was shoehorned through since that effectively will kill the whole project before it starts. Take the rest of the week to get rid of the silly boilerplate many people have already pointed at and be fully honest (c'mon, we *are* talking about a homogeneous group of people who don't have a lot of traceble experience with open source, go out and say so) about everything in the proposal, then start a new vote, giving people enough time to review what changed. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Could you please just restart the vote? AND, given the chatter and discussion, could you post the final proposal to the mail list again for a vote? I'm not trying to slow this down, but after all the muss and fuss, 3 more days won't kill it, and it will be clearer (at least to me...) to have what we're actually voting on in the archives. Just my 0.02 geir Sam Ruby wrote: When I originally kicked off this vote, I specified today, midnight, as the 72-hour-and-then-some deadline. Since then the proposal got a substantial revision (in particular, a new name) on Tuesday afternoon, so extending this a few hours to 4PM PST seems in order. I believe that the current wiki page: http://wiki.apache.org/incubator/KabukiProposal addresses all if not most of the concerns expressed by Roy, Leo, and Erik, each of which had expressed an explicit -1, and would be very interested to hear if this is in fact the case or if there are second order concerns that need to be brought forward. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
On 17.01.2006, at 03:55, David Crossley wrote: Erik Abele wrote: +1 - I don't know how to add this to the incubator-site myself (is anakia now ready to use?) but I'd really like to see this somewhere on incubator.a.o, e.g. http://incubator.apache.org/faq.html... Not yet ready. Lack of staff: http://marc.theaimsgroup.com/?t=11371964702 Incubator site status wrt a move to Anakia? So continue with the current method. Edit the existing source and leave the generation to someone else: http://incubator.apache.org/guides/website.html I don't have karma for that part of the repo (though I could certainly add myself to it) - any takers? I will send a patch in later today (I'm GMT+8.00) if no-one beats me to it, work at the moment so can't right this minute. I've not the karma but hope the patch will help anyway. Gav... Cheers, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
On Jan 17, 2006, at 6:13 PM, Andrew Clark wrote: [1] http://wiki.apache.org/incubator/KabukiProposal To be clear: +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Andrew, can you just shortly reply to the technical questions Martin Cooper has raised on this list? I do think he has a valid point there, and I'd like to hear what you have to say to that. Plus, please add me in as a committer. If this is to be incubated, I'd rather than not be part of it to be able to help out with downstream integration. regards, Martin On 1/18/06, Jim Jagielski [EMAIL PROTECTED] wrote: On Jan 17, 2006, at 6:13 PM, Andrew Clark wrote: [1] http://wiki.apache.org/incubator/KabukiProposal To be clear: +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Martin Marinschek wrote: can you just shortly reply to the technical questions Martin Cooper has raised on this list? I do think he has a valid point there, and I'd like to hear what you have to say to that. I went back to the archives and re-read all of Martin's posts on this topic but failed to find any specific technical arguments. We'd love the chance to discuss any technical issues regarding the proposed codebase, so if Martin's not too busy, it would be great if he could write up some of the specific problems he has with the current architecture. Plus, please add me in as a committer. If this is to be incubated, I'd rather than not be part of it to be able to help out with downstream integration. Done. :) -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
I don't recall anymore what he said specifically - did he talk about namespacing? do you do that? regards, Martin On 1/18/06, Andrew Clark [EMAIL PROTECTED] wrote: Martin Marinschek wrote: can you just shortly reply to the technical questions Martin Cooper has raised on this list? I do think he has a valid point there, and I'd like to hear what you have to say to that. I went back to the archives and re-read all of Martin's posts on this topic but failed to find any specific technical arguments. We'd love the chance to discuss any technical issues regarding the proposed codebase, so if Martin's not too busy, it would be great if he could write up some of the specific problems he has with the current architecture. Plus, please add me in as a committer. If this is to be incubated, I'd rather than not be part of it to be able to help out with downstream integration. Done. :) -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Martin Marinschek wrote: I don't recall anymore what he said specifically - did he talk about namespacing? do you do that? I was unable to find anything specific to comment on. Most of Martin Cooper's comments in his posts were about the technology being too immature and that he felt (after looking at the codebase) that is was the old way of doing things. But nothing specific about why he felt that way. But I'm confident that he'll respond shortly with specific concerns that we can discuss. Namespacing is an interesting issue as related to JavaScript programming. There's no inherent namespace support in the language so there's generally two approaches people take: 1) class name prefixes; and 2) nested objects to mimic packages. The Zimbra code (as well as Yahoo and Google, from what I've seen) uses the first approach. You could argue that it's less clean than the other approach but it's certainly more efficient because you don't have to perform all those dereferences to get to the object you're interested in. For example: AjxDateUtil vs. com.zimbra.util.DateUtil. I personally don't have a huge preference for one over the other but when you have more and more client side code, every little bit of performance helps. -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
For me, the first approach suffices. regards, Martin On 1/18/06, Andrew Clark [EMAIL PROTECTED] wrote: Martin Marinschek wrote: I don't recall anymore what he said specifically - did he talk about namespacing? do you do that? I was unable to find anything specific to comment on. Most of Martin Cooper's comments in his posts were about the technology being too immature and that he felt (after looking at the codebase) that is was the old way of doing things. But nothing specific about why he felt that way. But I'm confident that he'll respond shortly with specific concerns that we can discuss. Namespacing is an interesting issue as related to JavaScript programming. There's no inherent namespace support in the language so there's generally two approaches people take: 1) class name prefixes; and 2) nested objects to mimic packages. The Zimbra code (as well as Yahoo and Google, from what I've seen) uses the first approach. You could argue that it's less clean than the other approach but it's certainly more efficient because you don't have to perform all those dereferences to get to the object you're interested in. For example: AjxDateUtil vs. com.zimbra.util.DateUtil. I personally don't have a huge preference for one over the other but when you have more and more client side code, every little bit of performance helps. -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Andrew Clark wrote: Martin Marinschek wrote: can you just shortly reply to the technical questions Martin Cooper has raised on this list? I do think he has a valid point there, and I'd like to hear what you have to say to that. I went back to the archives and re-read all of Martin's posts on this topic but failed to find any specific technical arguments. We'd love the chance to discuss any technical issues regarding the proposed codebase, so if Martin's not too busy, it would be great if he could write up some of the specific problems he has with the current architecture. Another concern IIRC was download size. I remember (possibly incorrectly) that the toolkit has quite a large download before it will work, while other toolkits download piecemeal as required. disclaimerThis is purely from memory and I haven't looked at the code, so if I'm completely wrong, please just say so, then ignore me!/disclaimer Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Just a couple comments on Zimbra's motivations :-) Zimbra has absolutely no commercial interest or monetization goals around its Ajax toolkit. We are a collaboration software company and not a software tools company. We do have a very strong interest in ensuring the success of Ajax in a *non-proprietary* form. We felt that it would be a positive action to contribute our toolkit to the ASF and to try and build a community around it. Our thinking was that a codebase on which some fairly sophisticated apps have been developed would be of interest to the community. Additionally, Zimbra's products borrow code from the Open Source community (a lot of it from Apache), and we thought that it would be the right thing to do to give back to the community. We believed that making the toolkit freely available for folks to use and contribute to, was one of the ways in which we could achieve this. Thanks Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Upayavira wrote: Another concern IIRC was download size. I remember (possibly incorrectly) that the toolkit has quite a large download before it will work, while other toolkits download piecemeal as required. That's certainly one approach. And there are good reasons for doing it all together, as well. For example, some users have high-bandwidth but high-latency which makes it better to push as much through in one go instead of doing it piecemeal. And you could argue that most apps will need all of the widgets in the core set anyway. In the Zimbra product, we've done a lot of little tricks to help improve the download of resources (e.g. source, images, etc) for a variety of clients. Some of these tricks are the standard MO for JavaScript programmers, while others are based on experience and browser usage. Here's a list of some of them: * source is jammed together into a single file, removing comments and extraneous whitespace * icon images are merged into a single image and coupled with CSS to display them properly * images are pre-loaded to avoid browsers making multiple trips for the same image (because even though it's in the cache, some browsers -- and I won't name names ;) -- don't realize that immediately) In the end, it's a judgement call between which approach you take. -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
+1 on the proposal. I am assuming that the project will not have a generic technology name (Roy's point) but I'm not withholding my vote for that. On Jan 16, 2006, at 9:12 PM, Sam Ruby wrote: Erik Abele wrote: On 16.01.2006, at 02:42, Sam Ruby wrote: The discussion has died down, and the time has come to call for a VOTE to see if the incubator wants to sponsor and accept this proposal for incubation. As Roy and Leo (and others?) already noted, the proposal as sent is lacking some vital information - so for the time being I'd like to express another -1 here (peanut-gallery, yada yada...). The questions to date (which proposal are we talking about? Does it identify the committers and mentors by name? Is it on the wiki) are all answered here: http://wiki.apache.org/incubator/AjaxProposal Note: this does *not* address Roy's concern that the name represents a general category instead of a simple product name. And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Andy, any preference? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Sam Ruby wrote: And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Andy, any preference? I don't have any particular preference in regards to the name. If people have a problem with AjaxTk being too broad, then any other name will do. I have a natural preference towards Japanese names, though, so I'll suggest Kabuki. :) -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Justin Erenkrantz wrote: I see .java files - that has nothing to do with AJAX, so I'm sort of confused. I'd be expecting to see, well, only JavaScript. [...] If it has .java files, it isn't a 'client library'. So, I want to make sure we clarify where the boundaries are, so stupid people like me can make calls as to whether there's scope creep or not. Without communication to the host server, AJAX is just JavaScript in a web page. So there is a natural tendency to have server-side infrastructure to complete the AJAX programming model. At a basic level, there's a need to provide localized content for the application running in the browser. For example, in the Zimbra client, we put all of the resources in a standard Java .properties file and have a simple servlet detect the preferred language, load the resources (merging them), and return the data as a JS class. And at a higher level, there's a need for authorization, notification, etc. While this submission starts with the primary widget toolkit needed to start building AJAX applications, there is a need for server-side code to complete the model. And Java is a natural solution for this part and it ties in nicely with Tomcat and other solutions already at Apache. I hope this helps explain why there is some Java code in the client library. And, as for scope, I don't think the AJAX toolkit will stop simply at client-side widgets because that's only half of the picture. But I think we can start there and have it grow/evolve over time. -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Hi folks, First off, I would like to thank everyone for taking interest in the ajax toolkit incubator proposal and for the time folks are taking in providing feedback. From reading the various postings, there seems to be three areas of concern: 1) Project name. The issue here seems to be that the project name not be too general. I think that fixing this should not be a big issue. 2) Scope. Concern here stems around the breadth of the project. I think that some folks may be having some trouble drawing a box around what exactly is included in the scope of this project. Bottom line this project provides an SDK for developing ajax apps. The SDK includes the usual things one would expect such as network programming packages, utilities, UI components etc. There is a whitepaper on the Zimbra website that provides an overview of what is included in the toolkit. The URL for it is: http://www.zimbra.com/pdf/Zimbra AJAX TK Whitepaper.pdf 3) Technical issues. This is the area where I personally would love to see some more concrete discussion. From the various posts, it seems that a some folks have issues with the architecture and/or implementation of the code that Zimbra is contributing. I am having trouble diserning what exactly these concerns/issues are. I think it would be great if those with such concerns could perhaps post some details so that we can get some discussion going around them. Cheers Ross
Re: [VOTE] AJAX Toolkit Proposal - Updated
--On January 17, 2006 11:36:23 AM -0800 Andrew Clark [EMAIL PROTECTED] wrote: While this submission starts with the primary widget toolkit needed to start building AJAX applications, there is a need for server-side code to complete the model. And Java is a natural solution for this part and it ties in nicely with Tomcat and other solutions already at Apache. I hope this helps explain why there is some Java code in the client library. And, as for scope, I don't think the AJAX toolkit will stop simply at client-side widgets because that's only half of the picture. But I think we can start there and have it grow/evolve over time. Thanks. Before I would vote +1, I'd like to see this mentioned in the proposal (that is, it intends to create server-side code as well) so that this is clear from the project's outset. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
On Tue, 17 Jan 2006, Andrew Clark wrote: Justin Erenkrantz wrote: I see .java files - that has nothing to do with AJAX, so I'm sort of confused. I'd be expecting to see, well, only JavaScript. [...] If it has .java files, it isn't a 'client library'. So, I want to make sure we clarify where the boundaries are, so stupid people like me can make calls as to whether there's scope creep or not. Without communication to the host server, AJAX is just JavaScript in a web page. So there is a natural tendency to have server-side infrastructure to complete the AJAX programming model. While some AJAX toolkits do include server side code (e.g. Zimbra, DWR), others do not (e.g. Prototype, Dojo). There are pros and cons on both sides. You've detailed some of the advantages of providing it; the main down side would seem to be that it could slow adoption by those who are building their web apps with other server side languages, or even dissuade them from using it. Of course, you could always add support for other languages as well, assuming there are no ties to Java. My 2 cents. -- Martin Cooper At a basic level, there's a need to provide localized content for the application running in the browser. For example, in the Zimbra client, we put all of the resources in a standard Java .properties file and have a simple servlet detect the preferred language, load the resources (merging them), and return the data as a JS class. And at a higher level, there's a need for authorization, notification, etc. While this submission starts with the primary widget toolkit needed to start building AJAX applications, there is a need for server-side code to complete the model. And Java is a natural solution for this part and it ties in nicely with Tomcat and other solutions already at Apache. I hope this helps explain why there is some Java code in the client library. And, as for scope, I don't think the AJAX toolkit will stop simply at client-side widgets because that's only half of the picture. But I think we can start there and have it grow/evolve over time. -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Andrew Clark wrote: Sam Ruby wrote: And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Andy, any preference? I don't have any particular preference in regards to the name. If people have a problem with AjaxTk being too broad, then any other name will do. I have a natural preference towards Japanese names, though, so I'll suggest Kabuki. :) That does seem like a very fitting name. Can I ask you to create the following page, and fold in your answer to Justin's concern? http://wiki.apache.org/incubator/KabukiProposal - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
how about AJAX? :) Yoav Shapira wrote: Hola, I'll chime in with some name ideas just for consideration ;) And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Mmm, yeah, maybe that's just you ;) natural preference towards Japanese names, though, so I'll suggest Kabuki. :) Kabuki is not bad, though somewhat old-fashioned, no? Here are a couple of Japanese ones: - abarenbo (a hooligan ;)) - aite (the person/entity with which you share something: nice for AJAX since it does depend on some server-side stuff, whatever language you choose) - gumbai (ancient, hand-crafted fan used by sumo referees, and yes, most of my knowledge of japanese comes from being a sumo fan) - haru (spring, as in rebirth) - ketsudan (determination) - yukata (summer kimono, connotation of lightweight, airy...) -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Yoav Shapira wrote: natural preference towards Japanese names, though, so I'll suggest Kabuki. :) Kabuki is not bad, though somewhat old-fashioned, no? I guess I'm an old-fashioned kind of guy. :) Actually, my favorite traditional Japanese art is bunraku even though I (sadly) have not seen it in real-life. - abarenbo (a hooligan ;)) - aite (the person/entity with which you share something: nice for AJAX since it does depend on some server-side stuff, whatever language you choose) - gumbai (ancient, hand-crafted fan used by sumo referees, and yes, most of my knowledge of japanese comes from being a sumo fan) - haru (spring, as in rebirth) - ketsudan (determination) - yukata (summer kimono, connotation of lightweight, airy...) I remember going to a sumo basho in Tokyo about 4 years ago. What a blast! And even though I was in the nose-bleed seats (and thus couldn't throw my mat when I disagreed with a match), I could still hear the thunderous slap of the sumos' immense bodies hitting. nazukashii... I went ahead and changed the proposal name to Kabuki on the Incubator Wiki[1]. While I really like your sumo- inspired suggestions, I figured kabuki was one of the few words that even Westerners could identify (besides the obvious hibachi, sushi, sake, and karaoke). And it offers some interesting possibilities for logos. Anyway, we can always change the name later if we want to -- I just want to resolve some of the current issues with the proposal and move forward. [1] http://wiki.apache.org/incubator/KabukiProposal -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated (Again)
I have made a few modifications to the Ajax proposal Wiki page[1] in an attempt to resolve a few of the issues people have raised. The changes include: * Changed name to Kabuki * Added text to clarify the scope of the project Please let me know if there are any other issues that should be addressed by changes to the proposal text. Please note that the name change requires you to update any bookmarks you may already have for the old link. [1] http://wiki.apache.org/incubator/KabukiProposal - Original Message - From: Sam Ruby [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Tuesday, January 17, 2006 1:03:59 PM Subject: Re: [VOTE] AJAX Toolkit Proposal - Updated Andrew Clark wrote: Sam Ruby wrote: And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Andy, any preference? I don't have any particular preference in regards to the name. If people have a problem with AjaxTk being too broad, then any other name will do. I have a natural preference towards Japanese names, though, so I'll suggest Kabuki. :) That does seem like a very fitting name. Can I ask you to create the following page, and fold in your answer to Justin's concern? http://wiki.apache.org/incubator/KabukiProposal - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
-1. * There is no proposal in this email nor a URL reference to one. It looks like an attachment was stripped or something. Attachments suck. * it should have a different name from AJAX toolkit (and someone should update whatever docs we have to note that projects should have distinctive names). IIRC someone mentioned that already before. So ehm, phrased a little differently... * could we get a diff between the original and the revised proposal? * where is the revised proposal? * some work to do still, one easily spotted, might be others? This feels like yet another warning sign that makes me just a tad uncomfortable... Yes, I'm being lazy. I sometimes get like that when I have just 72 hours to respond and thousands of emails in a backlog :-) - LSD PS: And Ross, dude, you're just talking to a bunch of hackers, to whom it may concern is a phrase that actually gets .5 points from my spamassassin filter :-) On Sun, Jan 15, 2006 at 08:42:17PM -0500, Sam Ruby wrote: The discussion has died down, and the time has come to call for a VOTE to see if the incubator wants to sponsor and accept this proposal for incubation. Recap: * This has been scaled back - no umbrella or Eclipse plugins here. If accepted, it will be entirely up to the ASF to determine how this will evolve. * This is not meant to be exlusive - other related efforts are welcome to merge or continue separately. Furthermore, no ASF projects will be coerced into using this code. * This is to be evaluted for acceptance into incubation, not against criteria for exiting incubator. I've intentionally counciled for this proposal to present a realistic assessment of the current state, so everybody can best determine how to focus incubation efforts. It is customary to allow at least 72 hours for a vote, so lets see if we can get all votes in by 11:59pm PST on Thursday, Jan 19th. My vote: +1 - Sam Ruby Original Message Subject: AJAX Toolkit Proposal - Updated Date: Tue, 10 Jan 2006 23:07:00 -0800 (PST) From: Ross Dargahi [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org CC: aclark [EMAIL PROTECTED], Sam Ruby [EMAIL PROTECTED] To whom it may concern: Enclosed please find a revised contribution proposal for the Ajax Toolkit which takes into account the principal feedback that we have received to date. We welcome a further dialog on the merits of this submission. Thank you for your consideration. Regards Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] AJAX Toolkit Proposal - Updated
Sam, As others have suggested, please attach the proposal. Is this a vote on the proposal contained in Message-ID: [EMAIL PROTECTED] posted by Ross Dargahi on January 11, 2006? I believe that many of the complaints people have raised previously, or currently, can be addressed by renaming the thing to something that doesn't seem to co-opt a category (AJAX) for a project. No one knows how the project will evolve, but at least initially, the codebase is a specific donation, although we cannot use that name because it is also the name of the donating company. As I understand it, there is a general consensus that: - we need to appropriately name the project. - recognize that it is just one toolkit, not an exclusive location for the general technology within the ASF. - the initial codebase is just that: initial. Once the code is here, if people feel that the code sucks or the architecture sucks, or whatever else someone wants to complain about, all parties understood that the future direction of the architecture and code is, as is everything at the ASF, subject to communal will. - Other contributors interested in AJAX, with or without existing codebases, are free to contribute, or to propose additional AJAX-related projects. I do see clear interest in AJAX. Portals, MyFaces, and others (plus I know of an outside project or two that would be interested in contributing), can all make use of AJAX. Whether or not *this* project provides anything useful to them will depend on who participates and where the project goes as it evolves. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] AJAX Toolkit Proposal - Updated
Roy T. Fielding wrote: we get an umbrella every time we approve a project named after a technology *space* instead of a product. Just to nitpick, I feel that the Directory project has done a fine job of avoiding umbrella-ship, despite serving up a number of directory service related protocols and services within their unified server. And we have managed to created an umbrella that isn't named after a technology space. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Noel J. Bergman wrote: Sam, As others have suggested, please attach the proposal. Is this a vote on the proposal contained in Message-ID: [EMAIL PROTECTED] posted by Ross Dargahi on January 11, 2006? Yes, and I've copy and pasted it below. I'd put it in the wiki, but that requires a name. ;-) I believe that many of the complaints people have raised previously, or currently, can be addressed by renaming the thing to something that doesn't seem to co-opt a category (AJAX) for a project. No one knows how the project will evolve, but at least initially, the codebase is a specific donation, although we cannot use that name because it is also the name of the donating company. As I understand it, there is a general consensus that: - we need to appropriately name the project. Sure, let's name it after a region in the south pacific, as we all know that prevents the formation of an umbrella project (just having a little fun here...). Perhaps Andy can suggest a cool Japanese word (or location name)? - recognize that it is just one toolkit, not an exclusive location for the general technology within the ASF. +1 - the initial codebase is just that: initial. Once the code is here, if people feel that the code sucks or the architecture sucks, or whatever else someone wants to complain about, all parties understood that the future direction of the architecture and code is, as is everything at the ASF, subject to communal will. +1 - Other contributors interested in AJAX, with or without existing codebases, are free to contribute, or to propose additional AJAX-related projects. +1 I do see clear interest in AJAX. Portals, MyFaces, and others (plus I know of an outside project or two that would be interested in contributing), can all make use of AJAX. Whether or not *this* project provides anything useful to them will depend on who participates and where the project goes as it evolves. +1 - Sam Ruby AJAX Toolkit Proposal 0. Rationale While the term AJAX (Asynchronous Javascript and XML) has only recently been coined, the underlying web standards and technologies (JavaScript a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years. Although the term is used in a variety of ways, AJAX typically describes techniques towards developing interactive applications on the web client including asynchronous messaging, use of XML grammar in client-side applications, incremental page updates, and improved user interface controls. AJAX applications combine the rich UI experience of programmed clients with the low-cost lifecycle management of web-based applications. AJAX has raised awareness of the high potential of web applications, it has encouraged companies to adopt rich web-based interfaces over traditional fat clients, and it has spawned development activity to create toolkits and abstractions to make AJAX-style development easier and more powerful. This is an important trend for open source. The client itself can be composed entirely of open-source parts, such as Mozilla's Firefox or KDE's Konqueror, and does not require any particular operating system, helping to make a more level playing field for all development. More importantly, AJAX is back-end agnostic as transactions are done over HTTP. Keeping the client open forces vendors to keep the communication channel open as well, and this can only continue as long as the client technology keeps pace with proprietary alternatives. The open, standards based communications channel is what drives many technologies inside Apache, so success of the open client is vital to Apache. The mission of this project is to encourage innovation around enterprise-strength client runtimes and tools and build a community which can select and nurture a select set which will be most beneficial to the web. 0.1 Criteria Meritocracy: Apache was chosen for an incubator primarily because of the guidance the community can provide. Community: The contributed work was inspired by open source development but needs a strong and diverse community to validate its mission and carry it forward. A primary objective of the project is to build a vibrant community of users and active contributors. Core Developers: All of the initial committers are members of the Zimbra development team s . All developers have worked on open source projects before and have experience and understanding of open source principles. Alignment: The Zimbra AJAX Development Toolkit provides a rich client library, similar in style to traditional object-oriented widget libraries like Eclipse's SWT. This toolkit hides implementation details and browser quirks and makes web development more accessible to the enterprise developer. It provides * User interface development * Network communications (both synchronous and asynchronous) * SOAP programming * XML document creation and manipulation * UI event handling and management For further information, please see the Zimbra
RE: [VOTE] AJAX Toolkit Proposal - Updated
Sam, - we need to appropriately name the project. Sure, let's name it after a region in the south pacific Truk? JAAT? [Just Another AJAX Toolkit] I don't care. We seem to agree on the rest, but the proposal should make it clear, since those are points that appear to concern (some) others. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
Noel J. Bergman wrote: We seem to agree on the rest, but the proposal should make it clear, since those are points that appear to concern (some) others. To be honest, I would rather those points be placed on an general incubator page as they apply to every proposal. * No codebase within the ASF is to be considered an exclusive location for a general technology within the ASF. * All initial codebases are just that: initial. Once the code is here, if people feel that the code sucks or the architecture sucks, or whatever else someone wants to complain about, all parties understood that the future direction of the architecture and code is, as is everything at the ASF, subject to communal will. * Other contributors interested in any ASF codebase, with or without existing codebases, are free to contribute, or to propose additional related projects. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
On 16.01.2006, at 02:42, Sam Ruby wrote: The discussion has died down, and the time has come to call for a VOTE to see if the incubator wants to sponsor and accept this proposal for incubation. As Roy and Leo (and others?) already noted, the proposal as sent is lacking some vital information - so for the time being I'd like to express another -1 here (peanut-gallery, yada yada...). And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] AJAX Toolkit Proposal - Updated
On 17.01.2006, at 00:33, Sam Ruby wrote: Noel J. Bergman wrote: We seem to agree on the rest, but the proposal should make it clear, since those are points that appear to concern (some) others. To be honest, I would rather those points be placed on an general incubator page as they apply to every proposal. * No codebase within the ASF is to be considered an exclusive location for a general technology within the ASF. 'No codebase' plus 'or project' to catch umbrella's we still have... * All initial codebases are just that: initial. Once the code is here, if people feel that the code sucks or the architecture sucks, or whatever else someone wants to complain about, all parties understood that the future direction of the architecture and code is, as is everything at the ASF, subject to communal will. * Other contributors interested in any ASF codebase, with or without existing codebases, are free to contribute, or to propose additional related projects. +1 - I don't know how to add this to the incubator-site myself (is anakia now ready to use?) but I'd really like to see this somewhere on incubator.a.o, e.g. http://incubator.apache.org/faq.html... Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] AJAX Toolkit Proposal - Updated
Erik Abele wrote: On 16.01.2006, at 02:42, Sam Ruby wrote: The discussion has died down, and the time has come to call for a VOTE to see if the incubator wants to sponsor and accept this proposal for incubation. As Roy and Leo (and others?) already noted, the proposal as sent is lacking some vital information - so for the time being I'd like to express another -1 here (peanut-gallery, yada yada...). The questions to date (which proposal are we talking about? Does it identify the committers and mentors by name? Is it on the wiki) are all answered here: http://wiki.apache.org/incubator/AjaxProposal Note: this does *not* address Roy's concern that the name represents a general category instead of a simple product name. And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Andy, any preference? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
On 17.01.2006, at 03:12, Sam Ruby wrote: Erik Abele wrote: On 16.01.2006, at 02:42, Sam Ruby wrote: The discussion has died down, and the time has come to call for a VOTE to see if the incubator wants to sponsor and accept this proposal for incubation. As Roy and Leo (and others?) already noted, the proposal as sent is lacking some vital information - so for the time being I'd like to express another -1 here (peanut-gallery, yada yada...). The questions to date (which proposal are we talking about? Does it identify the committers and mentors by name? Is it on the wiki) are all answered here: http://wiki.apache.org/incubator/AjaxProposal Note: this does *not* address Roy's concern that the name represents a general category instead of a simple product name. This is a lot better; I missed your follow-up while replying and the former one didn't include any links... Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] AJAX Toolkit Proposal - Updated
Erik Abele wrote: +1 - I don't know how to add this to the incubator-site myself (is anakia now ready to use?) but I'd really like to see this somewhere on incubator.a.o, e.g. http://incubator.apache.org/faq.html... Not yet ready. Lack of staff: http://marc.theaimsgroup.com/?t=11371964702 Incubator site status wrt a move to Anakia? So continue with the current method. Edit the existing source and leave the generation to someone else: http://incubator.apache.org/guides/website.html -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
On 17.01.2006, at 03:55, David Crossley wrote: Erik Abele wrote: +1 - I don't know how to add this to the incubator-site myself (is anakia now ready to use?) but I'd really like to see this somewhere on incubator.a.o, e.g. http://incubator.apache.org/faq.html... Not yet ready. Lack of staff: http://marc.theaimsgroup.com/?t=11371964702 Incubator site status wrt a move to Anakia? So continue with the current method. Edit the existing source and leave the generation to someone else: http://incubator.apache.org/guides/website.html I don't have karma for that part of the repo (though I could certainly add myself to it) - any takers? Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] AJAX Toolkit Proposal - Updated
On Sun, Jan 15, 2006 at 08:42:17PM -0500, Sam Ruby wrote: The discussion has died down, and the time has come to call for a VOTE to see if the incubator wants to sponsor and accept this proposal for incubation. Looking at the wiki page and a cursory glance at the source, my question is one of scope: Where does Ajax Toolkit fit in the entire development/content model? (FWIW, I'd no problems calling it AjaxTK if Zimbra permitted.) I see .java files - that has nothing to do with AJAX, so I'm sort of confused. I'd be expecting to see, well, only JavaScript. So, I'm not so sure that the following statement is accurate: The Zimbra AJAX Development Toolkit provides a rich client library, similar in style to traditional object-oriented widget libraries like Eclipse's SWT. This toolkit hides implementation details and browser quirks and makes web development more accessible to the enterprise developer. It provides If it has .java files, it isn't a 'client library'. So, I want to make sure we clarify where the boundaries are, so stupid people like me can make calls as to whether there's scope creep or not. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
+1 from me. -- dims PS: why was eclipse plugins removed? (/me lazy to browse all the emails again!) On 1/15/06, Sam Ruby [EMAIL PROTECTED] wrote: The discussion has died down, and the time has come to call for a VOTE to see if the incubator wants to sponsor and accept this proposal for incubation. Recap: * This has been scaled back - no umbrella or Eclipse plugins here. If accepted, it will be entirely up to the ASF to determine how this will evolve. * This is not meant to be exlusive - other related efforts are welcome to merge or continue separately. Furthermore, no ASF projects will be coerced into using this code. * This is to be evaluted for acceptance into incubation, not against criteria for exiting incubator. I've intentionally counciled for this proposal to present a realistic assessment of the current state, so everybody can best determine how to focus incubation efforts. It is customary to allow at least 72 hours for a vote, so lets see if we can get all votes in by 11:59pm PST on Thursday, Jan 19th. My vote: +1 - Sam Ruby Original Message Subject: AJAX Toolkit Proposal - Updated Date: Tue, 10 Jan 2006 23:07:00 -0800 (PST) From: Ross Dargahi [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org CC: aclark [EMAIL PROTECTED], Sam Ruby [EMAIL PROTECTED] To whom it may concern: Enclosed please find a revised contribution proposal for the Ajax Toolkit which takes into account the principal feedback that we have received to date. We welcome a further dialog on the merits of this submission. Thank you for your consideration. Regards Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
