Re: ajax proposal?
Andrew Clark wrote: Raphaël Luta wrote: - no source control access We have read-only CVS access[1] already for the entire project. The details should definitely be more visible, though. I'll talk to someone about getting it more prominent on the main site. I missed the link. It should indeed be more visible :) I understand that you wouldn't want to setup your own public dev infrastructure but using sf.net, codehaus, tigris or whatever public infra wouldn't have been very onerous. My concern here is if no resources have been dedicated so far to really build the AjaxTk into an OSS project why would that change once it is in incubation ? Let me try to summarize what I think your point is and you can tell me if I'm wrong. You would feel better about the submission if it were already a fully formed OSS project on an external site with full development infrastructure and long-time active community. Is this accurate? The long time active community is not accurate and building such a community is a main reason for the Incubator. As far I can tell, what needs to happen to fully OSS AjaxTk is something like this: - cleanup the code/doc/install so that Tk can be consumed by a public community - rework a clear internal separation between AjaxTk and ZCS with different repos, dependency management, indep release cycle, and so on... - adjust internal dev processes to deal with the public infra (and possibly some early external dev) - start building a long term external community by actively attracting new committers I would feel more comfortable if the first 3 steps would be done somewhere else before any incubation starts so that incubation can really focus on the last point. Apache does not bring any value in the first 3 steps that you can't bring by yourself as an ASF member and the amount of work and risk of failure in those 3 first steps is IMO significant. The benefit of such a 2 step process is that this gives you an actual public track record before incubation is decided and voids most concerns about incubation being a pure branding exercicse since a significant amount of work would already have been spent in making the AjaxTk OSS independantly of any Apache commitment. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Jan 25, 2006, at 12:24 AM, Raphaël Luta wrote: As far I can tell, what needs to happen to fully OSS AjaxTk is something like this: - cleanup the code/doc/install so that Tk can be consumed by a public communityIt seems to me that something that works in some cases but isn't fully developed as an end-user easy-to-use product is ideal to complete in the incubator. - rework a clear internal separation between AjaxTk and ZCS with different repos, dependency management, indep release cycle, and so on...Repository issues, build, test, separation of dependencies, etc. can be very repository-specific. If you build this infrastructure in source forge you would have to deal with similar but different issues here in Apache. Why require them to make two transitions? - adjust internal dev processes to deal with the public infra (and possibly some early external dev)IMHO this is a critical part of building a community. - start building a long term external community by actively attracting new committers I would feel more comfortable if the first 3 steps would be done somewhere else before any incubation starts so that incubation can really focus on the last point.Sorry, but I don't agree. The way the first 3 steps are handled will give the Apache community a good sense of whether this project "gets it" or not, and we might as well help them with the process sooner than later. Apache does not bring any value in the first 3 steps that you can't bring by yourself as an ASF member and the amount of work and risk of failure in those 3 first steps is IMO significant.I'm not sure that I understand your point. Certainly "any" open source repository is a different environment from a closed source, but I don't see an argument for or against incubation in Apache. The benefit of such a 2 step process is that this gives you an actual public track record before incubation is decided and voids most concerns about incubation being a pure branding exercicse since a significant amount of work would already have been spent in making the AjaxTk OSS independantly of any Apache commitment.I'd still say that there is significant breakage involved in taking a closed source through two migrations rather than one. I think we need to remain focused on the barrier to incubation as documented in the Apache policies and not try to create new processes on the fly.To me the critical piece here is "donation". These folks have intellectual property that appears to be useful and they want to donate it to Apache. Due diligence is required to make sure that there are people in Apache who want to see it succeed (mentors, sponsors, champions, developers, users), and there are resources available to build a community here. But let's not put artificial barriers in their way. There are plenty of barriers once in incubation.Craig -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: ajax proposal?
Raphaël Luta wrote: As far I can tell, what needs to happen to fully OSS AjaxTk is something like this: - cleanup the code/doc/install I would expect that at worst those would be early doings during Incubation. - rework a clear internal separation between AjaxTk and ZCS - adjust internal dev processes - start building a long term external community Those should happen by virtue of Incubation. Apache does not bring any value in the first 3 steps Actually, the second and third would happen by moving into the Incubator, and the first is something that multiple people could start to work on, once the code were moved into Subversion. A fascination with brand seems to be your primary concern, but if we end up killing the project because it doesn't evolve properly, that would make any such effort to leverage the Apache brand seriously counter-productive. Ask around for a favorable reaction to the Avalon project. Most people have a negative view of it, and anything it touched, despite the fact that the only problem with the project was a poisoned community. As an aside to Andrew Clark, acceptance is a policy decision, not a technical one; there isn't a veto option. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Sanjiva Weerawarana wrote: On Mon, 2006-01-23 at 13:38 +0100, Raphaël Luta wrote: Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. My admission bar for such proposals is set much higher than usual. With all due respect Raphael, I find this unreasonable. You can't make random admission bars for projects based on personal prejudices. What I suggest is that you join the project as a mentor and make sure push them hard to make sure they come out clean as whistle or hold them in incubation until its killed. That way you convince yourself that the project is good *from the ASF points of view* (community, meritocracy etc.) but not from things like visibility point of view which by no means are a requirement. I would agree with this if there was no immediate percieved benefit when you are in Incubator, unfortunately it seems projects under incubation are still perceived by the larger community as endorsed by Apache. As long as this is true, accepting a project in the incubator even if it stays there indefinitely *does* matter to me. In the end, I don't think it's a personal prejudice but more a lack of trust in the motivations of the proposal. What's the status of the vote? I'm confused by calls to repeal the vote and modifications to the vote and all that. I thought we were spsed to be a simple bunch of, um, people but it sure doesn't look like it! ;-) I'm confused too by the voting process and repeated proposals even before the discussion has died down. Am I spsed to vote my choice at this time or is there no vote going on? So confused. Must be the freezing weather in Sri Lanka these days. Its been like 65F in Colombo at nite. Brr. 27F here in Paris, It sure wakes you up in the morning :) -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Andrew Clark wrote: Raphaël Luta wrote: Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. Thanks for your answer Andy. It sure helps flesh out your motivations. The Zimbra product owes much of its success to open- source products, especially from Apache. The Kabuki submission for incubation is an attempt to give back to the community that's given us so much coupled with the fact that we believe browser-based client coding with Ajax is a natural fit with the web-centric theme of Apache projects. Here we completely agree that Ajax certainly has a place in the ASF. Our core business is collaboration and competing against Exchange server; we aren't a tools or toolkit company. As such, we are not associating the Zimbra brand with the toolkit and aren't planning on making money from this effort. I hope that goes a little way towards easing some people's concerns regarding the submission. I completely understand that you're not a toolkit company however I can't understand why the AjaxTk is currently in such a sore open-source state: - the code dumps on the site are not functional out of the box - no source control access - the sourceforge site is half configured and no links have been created to this tk (freshmeat, etc...) I understand that you wouldn't want to setup your own public dev infrastructure but using sf.net, codehaus, tigris or whatever public infra wouldn't have been very onerous. My concern here is if no resources have been dedicated so far to really build the AjaxTk into an OSS project why would that change once it is in incubation ? It could be done now in sf or codehaus. That would trigger all the zimbra internal changes that will have to happen to make such a task work (like how to manage the internal and external source repositories, commit access, bug reporting, public design decisions, etc...). You will pick an initial community then but most importantly work out the internal issues that are bound to happen. Proposing an to enter incubation from that situation would be a no-brainer for me. One last note... the Zimbra marketing guy is well aware that PR for incubated projects will not be allowed and he's completely cool with that. Zimbra wants to do the right thing and are willing to commit resources to try to make that happen. However, if the Apache community is still uneasy about the submission and denies its entry to incubation, so be it. But I would love to see Apache take a role in crafting the future of AJAX programming (with the added personal benefit of being paid to work on Apache technology again :). I think it's hard to speak for the Apache community ;) In the end, we're all individuals and certainly don't agree on everything. I'm not completely comfortable with the current proposal mostly because I am concerned by recent PR issues and I got concerned by the amount of boilerplate text in the different proposals (reading the current line on meritocracy still makes me cringe). -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Hi Raphael, I would agree with this if there was no immediate percieved benefit when you are in Incubator, unfortunately it seems projects under incubation are still perceived by the larger community as endorsed by Apache. If that's indeed the problem then we need to work on clearing up that misconception. That concern applies to all projects in the Incubator, not just this candidate. I don't see it as reasonable to reject this proposal on that basis. As long as this is true, accepting a project in the incubator even if it stays there indefinitely *does* matter to me. In the end, I don't think it's a personal prejudice but more a lack of trust in the motivations of the proposal. That's a very strong statement .. let's please keep this conversation totally civil and respectful. This proposal is, after all, being strongly supported by Sam, who's not just a 2-bit member like me but rather a board member that you and I and other members elected to look after the best interests of the foundation. I've known Sam for many years and he's stubborn as a deaf mule and the last person who will give into pressure from his employer to do something that will harm the ASF. Sam has consistently been jumping into new stuff and really having dramatic impact quickly and intensely. I suspect he will do the same with this and I don't expect the other people around him will enjoy every minute of it. (I know I haven't for the stuff I've been around with him for ;-)) I'm confused too by the voting process and repeated proposals even before the discussion has died down. I think the new vote was called after the discussion settled (or we jumped to another horse to beat on) but clearly things are in a confused state now. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Sanjiva Weerawarana wrote: What's the status of the vote? I'm confused by calls to repeal the vote and modifications to the vote and all that. I thought we were spsed to be a simple bunch of, um, people but it sure doesn't look like it! ;-) Overview of what occurred: 1) on 12/20, Adam Peller posted a proposal for comments (not a vote!). The most significant comments related to the inclusion of Eclipse components, and the perception of this being an umbrella. 2) on 1/15, I posted a signficantly reduced proposal for a vote. Missing from that proposal is any Eclipse componentry. Justin asked for a clarification regarding server components, and there were numereous requests for a new name. Some questions were raised as to whether a Zimbra employee could make an adequate mentor. On 1/19, Leo and Geir asked for a new vote. 3) on 1/23, I posted a new vote on a proposal now named Kabuki. Here are links to the current proposal, to the set of changes, and to the start of the current vote thread: http://wiki.apache.org/incubator/KabukiProposal http://tinyurl.com/e3egs http://tinyurl.com/7emr5 Am I spsed to vote my choice at this time or is there no vote going on? Yes there is a vote going on. Please do vote. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Raphaël Luta wrote: I completely understand that you're not a toolkit company however I can't understand why the AjaxTk is currently in such a sore open-source state: - the code dumps on the site are not functional out of the box To be precise, all of the toolkit (widgets, utils, etc) are completely functional. It's the infrastructure for the samples that need some work to make them work out of the box. - no source control access We have read-only CVS access[1] already for the entire project. The details should definitely be more visible, though. I'll talk to someone about getting it more prominent on the main site. I understand that you wouldn't want to setup your own public dev infrastructure but using sf.net, codehaus, tigris or whatever public infra wouldn't have been very onerous. My concern here is if no resources have been dedicated so far to really build the AjaxTk into an OSS project why would that change once it is in incubation ? Let me try to summarize what I think your point is and you can tell me if I'm wrong. You would feel better about the submission if it were already a fully formed OSS project on an external site with full development infrastructure and long-time active community. Is this accurate? It seems to me that if that were the case, then there would be little need to come to the Apache incubator with all the extra work and headaches of the process. There are certainly projects that seem to be natural extensions to Apache and thus, as someone put it, come home. But most fully-formed projects would have little need to come to Apache so I would be wary of them wanting the Apache brand. In this case, the Kabuki submission is an attempt to help kickstart the AJAX movement at Apache. And we're willing to work on that with other members of the community. But being in the Apache incubator certainly doesn't help us; it's actually a loss when you consider the time and resources that are taken away from our core business. And we're not doing it for the press 'cause that's simply not allowed until after a project exits incubation which could be years down the road. Anyway, we've probably had enough discussion and should just vote this up or down. If you feel that strongly about it, you can vote your -1 veto. Your other option is to let it pass but lodge your disapproval with a -0. [1] http://www.zimbra.com/forums/showthread.php?t=793 -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Noel J. Bergman wrote: Raphaël Luta wrote: Do we have other incubating projects following the Kabuki pattern, ie all initial committers from a single company with the mentor salaried by the same company ? I'd sure like to know how these evolved if we have any. Hmm ... I'd have to check, but XMLBeans, Beehive and Derby? Certainly Derby, which was brought in by IBM and Mentored by Ken and Sam. Interesting. Derby had 3 mentors so they would pass the 3 members check although they are all tied to the sponsor. Beehive seems to have had 2 members from the get go (dims and craig) none of them associated with the sponsor. XMLBeans had only 1 member/committer from the beginning but not affiliated with the sponsor. As far as i know, it has never been reviewed on the mailing-list probably because it didn't show up on the radar. So should we take the lack of use as a critique against anything other than visibility? No but should the ASF provide instant visibility to any framework without having the sponsor to work at least a little on the community before coming to the ASF ? Isn't AjaxTk already open-sourced ? If you want to try something, go on sf.net, freshmeat, etc... and try *finding* AjaxTk. It sure helps understand why it's not on anybody's radar. Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. My admission bar for such proposals is set much higher than usual. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Raphaël Luta wrote: Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. The Zimbra product owes much of its success to open- source products, especially from Apache. The Kabuki submission for incubation is an attempt to give back to the community that's given us so much coupled with the fact that we believe browser-based client coding with Ajax is a natural fit with the web-centric theme of Apache projects. Our core business is collaboration and competing against Exchange server; we aren't a tools or toolkit company. As such, we are not associating the Zimbra brand with the toolkit and aren't planning on making money from this effort. I hope that goes a little way towards easing some people's concerns regarding the submission. One last note... the Zimbra marketing guy is well aware that PR for incubated projects will not be allowed and he's completely cool with that. Zimbra wants to do the right thing and are willing to commit resources to try to make that happen. However, if the Apache community is still uneasy about the submission and denies its entry to incubation, so be it. But I would love to see Apache take a role in crafting the future of AJAX programming (with the added personal benefit of being paid to work on Apache technology again :). -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Mon, 2006-01-23 at 13:38 +0100, Raphaël Luta wrote: Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. My admission bar for such proposals is set much higher than usual. With all due respect Raphael, I find this unreasonable. You can't make random admission bars for projects based on personal prejudices. What I suggest is that you join the project as a mentor and make sure push them hard to make sure they come out clean as whistle or hold them in incubation until its killed. That way you convince yourself that the project is good *from the ASF points of view* (community, meritocracy etc.) but not from things like visibility point of view which by no means are a requirement. What's the status of the vote? I'm confused by calls to repeal the vote and modifications to the vote and all that. I thought we were spsed to be a simple bunch of, um, people but it sure doesn't look like it! ;-) Am I spsed to vote my choice at this time or is there no vote going on? So confused. Must be the freezing weather in Sri Lanka these days. Its been like 65F in Colombo at nite. Brr. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Noel J. Bergman wrote: Raphaël Luta wrote: do you really feel comfortable when the main point of oversight for the ASF in an incubated project is in the pay of the project sponsor and quite possibly internally reporting to one of the project committer ? The potential for conflict is huge and I would personnally hate to be in such an awkward position. I can think of examples supporting your view, but most probably support Roy's. By trying to get at least 3 ASF Members as active Mentors, perhaps we can better address the concern. Do we have other incubating projects following the Kabuki pattern, ie all initial committers from a single company with the mentor salaried by the same company ? I'd sure like to know how these evolved if we have any. I'm glad Martin has been added as a commmitter to Kabuli but I would feel much better about it if other existing memebrs/committers willing to work on that project would join. others from Portals may wish to give it a try but I somehow doubt it given that the toolkit didn't even show up in the short list when we first investigated the field for our AJAX support. Was it reviewed? Or just didn't show up on the radar? As far as i know, it has never been reviewed on the mailing-list probably because it didn't show up on the radar. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Roy T. Fielding wrote: On Jan 19, 2006, at 12:36 AM, Raphaël Luta wrote: We're doing loops here. My point in this thread is that initial code quality does matter in a code grant incubation because it is often burdened by backward compatibility with existing applications and thus major restructure may require a revolution which can hardly safely happen in the early months of the project open-source life. And all those points are wrong. There is no burden of backward compatibility because it must be an entirely new product -- all of the names change anyway. A major restructure is a good idea; that is, after all, why we founded Apache as a project to replace NCSA httpd 1.3R, which was replaced by Shambhala within 6 months. And it certainly doesn't have to happen safely -- the project is going to be shooting for TLP status, which means about a year or more under incubation before it can even do real releases, and the more hard decisions the group has to make (in public), the better they will learn how to collaborate. I fail to see how you can apply the httpd situation (standalone server, initial community with independant contributors, most downstream users relying on standard http/cgi) to the current proposal (development toolkit/framework, community with hierarhical relationships and downstream users code-dependant on toolkit). You take the optimistic view that the community would work as expected; I have a pessimistic view that it will not without some cost to the ASF if at all. Honestly, once the name is changed to something neutral like Kabuki, none of your objections make any sense. Especially the ones about code quality, since most of our projects started with code that needed a serious re-arch almost immediately. I would love to see three or four different ajax toolkits under the ASF, each with its own architectural focus, and let them compete for developers, but we can only approve one podling at a time. +1 I just wish they would join with a least a nucleus of public community. Meanwhile, I do think that any proposal to the Incubator needs at least three active Apache committers involved, preferably members that are willing to do infrastructure tasks. Incubator podlings are seriously infrastructure dependent and the existing volunteers are already tapped-out. +1 -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Raphaël Luta wrote: Do we have other incubating projects following the Kabuki pattern, ie all initial committers from a single company with the mentor salaried by the same company ? I'd sure like to know how these evolved if we have any. Hmm ... I'd have to check, but XMLBeans, Beehive and Derby? Certainly Derby, which was brought in by IBM and Mentored by Ken and Sam. I'm glad Martin has been added as a commmitter to Kabuli but I would feel much better about it if other existing memebrs/committers willing to work on that project would join. So would I, but community building often takes time. As far as i know, it has never been reviewed on the mailing-list probably because it didn't show up on the radar. So should we take the lack of use as a critique against anything other than visibility? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Raphaël Luta wrote: do you really feel comfortable when the main point of oversight for the ASF in an incubated project is in the pay of the project sponsor and quite possibly internally reporting to one of the project committer ? The potential for conflict is huge and I would personnally hate to be in such an awkward position. I can think of examples supporting your view, but most probably support Roy's. By trying to get at least 3 ASF Members as active Mentors, perhaps we can better address the concern. others from Portals may wish to give it a try but I somehow doubt it given that the toolkit didn't even show up in the short list when we first investigated the field for our AJAX support. Was it reviewed? Or just didn't show up on the radar? I don't see why incubating it would change in any way its fitness for our purpose. What makes you say that it isn't fit for the purpose? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Martin, Given that nobody else seems to share my views on the architecture I think that many of us are still waiting for some details, other than the namespace. or on the effect of the ASF brand on the AJAX world So we should pre-select projects for Incubation based upon whether or not the code, not the community, is best-of-breed and worthy of annointing? You know, some projects used to say that the incubating label put them in a potentially negativce light. given that the incubator appears to be a just knock and you're in project anyway Not quite, but how high do you want the bar, and still expect people to feel that they can bring projects here and try to innovate? And please note that getting in is not the same as getting out. Plus, if you want talk about projects worthy of annointing, or not, should we next go through existing TLPs and expel some because their code sucks? I've assumed pretty much from the get-go that I'm fighting a lost cause here. But that doesn't mean I want to go quietly. Fortitude, paired with a reasonable and rational nature, is a good thing. Don't apologize for it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Le 19 janv. 06 à 02:57, Noel J. Bergman a écrit : Raphaël Luta wrote: I thought it would be safe to assume that Zimbra collaboration suite uses the AjaxTk. If it doesn't then I'm even more worried about that codebase ;) Why? Because then I would have to reconsider the orphaned product statement of the proposal. Anyway, as far as I can tell froom looking at Zimbra collaborative suite, it does depend on the ajaxTk. An established codebase is *much* more difficult to restructure than starting from scratch. Apache SOAP - Apache Axis Tomcat 3 - Tomcat 4 - Tomcat 5 - Tomcat 5.5 ... Jetspeed 1 - Jetspeed 2 ;-) My point exactly ! Most of these transitions have not been a smooth ride even though they are successful: it takes time and a resilient community to manage these. No one said that doing it was necessarily easy, but isn't creating resilient, healthy, communities a major part of our purpose? We're doing loops here. My point in this thread is that initial code quality does matter in a code grant incubation because it is often burdened by backward compatibility with existing applications and thus major restructure may require a revolution which can hardly safely happen in the early months of the project open-source life. -- Raphaël Luta - [EMAIL PROTECTED] Apache Jetspeed - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Jan 19, 2006, at 12:18 AM, Raphaël Luta wrote: Le 19 janv. 06 à 03:03, Noel J. Bergman a écrit : Raphaël Luta wrote: What specific concerns do you have with this community and this codebase? - the mentor for this project is salaried by the project sponsor ! To date, we have said that an ASF Member is an individual, not an employeee. Mind you, we're also discussing that a project SHOULD have multiple Mentors. But do you really feel comfortable when the main point of oversight for the ASF in an incubated project is in the pay of the project sponsor and quite possibly internally reporting to one of the project committer ? The potential for conflict is huge and I would personnally hate to be in such an awkward position. I am in that position for Jackrabbit. It hasn't been a problem for me, but it was one of the reasons that I made sure we had several other ASF members involved as well. BTW, the main point of oversight is the PPMC as a whole, not the chair. It is relatively easy to see when that isn't happening. In any case, that is why we call them incubating projects. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Jan 19, 2006, at 12:36 AM, Raphaël Luta wrote: We're doing loops here. My point in this thread is that initial code quality does matter in a code grant incubation because it is often burdened by backward compatibility with existing applications and thus major restructure may require a revolution which can hardly safely happen in the early months of the project open-source life. And all those points are wrong. There is no burden of backward compatibility because it must be an entirely new product -- all of the names change anyway. A major restructure is a good idea; that is, after all, why we founded Apache as a project to replace NCSA httpd 1.3R, which was replaced by Shambhala within 6 months. And it certainly doesn't have to happen safely -- the project is going to be shooting for TLP status, which means about a year or more under incubation before it can even do real releases, and the more hard decisions the group has to make (in public), the better they will learn how to collaborate. Honestly, once the name is changed to something neutral like Kabuki, none of your objections make any sense. Especially the ones about code quality, since most of our projects started with code that needed a serious re-arch almost immediately. I would love to see three or four different ajax toolkits under the ASF, each with its own architectural focus, and let them compete for developers, but we can only approve one podling at a time. Meanwhile, I do think that any proposal to the Incubator needs at least three active Apache committers involved, preferably members that are willing to do infrastructure tasks. Incubator podlings are seriously infrastructure dependent and the existing volunteers are already tapped-out. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Sam Ruby wrote: Raphaël Luta wrote: Erik Abele wrote: It's just the initial code, nothing more :) I don't agree with this statement. The code itself is indeed only the initial codebase but along with this codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility snip I think my point is simply that in a code grant incubation scenario, initial codebase and initial community *do* matter because they'll act as natural forces towards stability and are likely to shape the community and codebase for a long time. Hopefully, at some point, these somewhat abstract discussion of concerns that are relevant to all proposals will solidify into concrete concerns regarding this specific proposal. I was simply in disagreement with Erik statement that initial code is not that important. It's tangential to the actual zimbra proposal. Is code irrelevant? That would be absurd. That's why the code has been made available for all to download, inspect and comment on. I think a more neutral restatement of what Eric and Noel are trying to say is that while good communities always overcome bad code, no amount of good code can make up for a bad community. While I more or less agree with this statement, I think that bad code can prevent a good community from happening in the first place, especially when good communities exist elsewhere. DisclaimerI've not reviewed the code so that statement above does not reflect any quality judgement on the proposed zimbra toolkit/Disclaimer On the other had, Raphaël, I see you making implicit assumptions that the committers will have entrenched interests that will be difficult to overcome, and that the existing community is mature. What evidence do you have of that? I'm sure that you can give examples of other communities where that was a problem, and I can give examples of other communities where that was NOT a problem. What do either examples prove? Nothing. What specific concerns do you have with this community and this codebase? If we're talking explicitly about the Zimbra proposal, here's my current understanding of the proposal : Of the 4 Criteria listed in the proposal, only 1 is met by the proposal: Alignment to ASF All 3 others are filled with boilerplate statements that indicate: - the project does not use at all a meritocratic model right now - there's no community - the core developers are strongly bound to a single entity with only Andy being easily traced to prior open source activity Of the 6 warning signs listed: - 1 is defintitely not met: the Zimbra toolkit is not an orphaned product - 1 is possibly met: Inexperience with open-source, again 30 minutes of Googling for the zimbra team show little oss credentials - 1 is probably met: fascination with Apache brand, but I'll admit it's a personal interpretation - 3 are definitively met: - reliance on salaried developers - homogenous developers (I'll admit that IMO if the 2 are often linked) - no ties to other apache products Additional personal expectations: - the Zimbra collaboration suite uses the AjaxTk so there will be some backward compatibility burden attached to the codebase. - if incubation is accepted, I expect a lot of PR noise around it due to hype surrounding AJAX and aggressive communication profile of Zimbra Positive signs: - the updated proposal has attempted to fix some of the issues raised after the first proposal that could be fixed (scope, number of initial committers) Negative signs: - the mentor for this project is salaried by the project sponsor ! - I can trace no public attempt to meet other possible user apache communities (myfaces, portals, cocoon, etc...) even after first proposal rejection - I see negative technical feedback on the proposal from ASF people I trust left unanswered When you put all this together, you can understand I'm hardly enthusiastic about this proposal. What would change my opinion ? 2 must have: - no PR before graduation - an independant mentor 1 nice to have: - some ties with a possible downstream community, possibly adding some of their committers in the initial committer pool -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Noel J. Bergman wrote: Raphaël Luta wrote: along with [a] codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility That carries a fairly large assumption, and really should be posed as a question, not an answer. I thought it would be safe to assume that Zimbra collaboration suite uses the AjaxTk. If it doesn't then I'm even more worried about that codebase ;) An established codebase is *much* more difficult to restructure than starting from scratch. Apache SOAP - Apache Axis Tomcat 3 - Tomcat 4 - Tomcat 5 - Tomcat 5.5 ... Jetspeed 1 - Jetspeed 2 ;-) My point exactly ! (and you could add httpd 1.x - httpd 2.x) Most of these transitions have not been a smooth ride even though they are successful: it takes time and a resilient community to manage these. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Raphaël Luta wrote: I thought it would be safe to assume that Zimbra collaboration suite uses the AjaxTk. If it doesn't then I'm even more worried about that codebase ;) Why? An established codebase is *much* more difficult to restructure than starting from scratch. Apache SOAP - Apache Axis Tomcat 3 - Tomcat 4 - Tomcat 5 - Tomcat 5.5 ... Jetspeed 1 - Jetspeed 2 ;-) My point exactly ! Most of these transitions have not been a smooth ride even though they are successful: it takes time and a resilient community to manage these. No one said that doing it was necessarily easy, but isn't creating resilient, healthy, communities a major part of our purpose? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Erik Abele wrote: Oh, of course - but for now there's no community yet so he is complaining into the blue sky :) I'd certainly like to see a response to the concerns raised by Martin but OTOH I don't think that it should evolve into a discussion about basic architectural principles or even impact the final consideration of incubation. It's just the initial code, nothing more :) I don't agree with this statement. The code itself is indeed only the initial codebase but along with this codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility An established codebase is *much* more difficult to restructure than starting from scratch. Even if someone would be willing to contribute to this projet to help address major technical issues, it would require a huge amount of effort to effect a significant architectural change because of community inertia and backward compatibility requirements. From what I've seen at Apache, major rearchitecture work always happen as a revolution with an entirely new implementation being built and these revolutions are dangerous to a project communiy health. Given the frictions created by revolutions, it's important that these do not happen before the community is mature else they may simply split it. I think my point is simply that in a code grant incubation scenario, initial codebase and initial community *do* matter because they'll act as natural forces towards stability and are likely to shape the community and codebase for a long time. Just my 2 eurocents, -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Raphaël Luta wrote: Erik Abele wrote: Oh, of course - but for now there's no community yet so he is complaining into the blue sky :) I'd certainly like to see a response to the concerns raised by Martin but OTOH I don't think that it should evolve into a discussion about basic architectural principles or even impact the final consideration of incubation. It's just the initial code, nothing more :) I don't agree with this statement. The code itself is indeed only the initial codebase but along with this codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility An established codebase is *much* more difficult to restructure than starting from scratch. Even if someone would be willing to contribute to this projet to help address major technical issues, it would require a huge amount of effort to effect a significant architectural change because of community inertia and backward compatibility requirements. From what I've seen at Apache, major rearchitecture work always happen as a revolution with an entirely new implementation being built and these revolutions are dangerous to a project communiy health. Given the frictions created by revolutions, it's important that these do not happen before the community is mature else they may simply split it. I think my point is simply that in a code grant incubation scenario, initial codebase and initial community *do* matter because they'll act as natural forces towards stability and are likely to shape the community and codebase for a long time. Hopefully, at some point, these somewhat abstract discussion of concerns that are relevant to all proposals will solidify into concrete concerns regarding this specific proposal. Is code irrelevant? That would be absurd. That's why the code has been made available for all to download, inspect and comment on. I think a more neutral restatement of what Eric and Noel are trying to say is that while good communities always overcome bad code, no amount of good code can make up for a bad community. On the other had, Raphaël, I see you making implicit assumptions that the committers will have entrenched interests that will be difficult to overcome, and that the existing community is mature. What evidence do you have of that? I'm sure that you can give examples of other communities where that was a problem, and I can give examples of other communities where that was NOT a problem. What do either examples prove? Nothing. What specific concerns do you have with this community and this codebase? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Tuesday 17 January 2006 14:27, Martin Cooper wrote: And the impact of giving a project the ASF brand. And the way the incubator operates as an open door to whoever knocks, with virtually no entry criteria. This seems to be a recurring (growing?) concern among people 'inside' ASF. Perhaps the membership+Board should discuss this matter and re-issue a clearer directive to the Incubator. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Martin Cooper wrote: the incubator operates as an open door to whoever knocks, with virtually no entry criteria. The criteria is that another PMC votes or the Incubator PMC votes. In the latter case, we should be looking to see interest from the Membership. In numerous cases, I can think of proposals that came and went with no fanfare, largely because no one was interested. When we DO see interest from ASF Members, I have no problem with a discussion to educate them if one feels that there are reasons to reconsider, but past that, isn't it just down to a vote? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Raphaël Luta wrote: along with [a] codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility That carries a fairly large assumption, and really should be posed as a question, not an answer. An established codebase is *much* more difficult to restructure than starting from scratch. Apache SOAP - Apache Axis Tomcat 3 - Tomcat 4 - Tomcat 5 - Tomcat 5.5 ... Jetspeed 1 - Jetspeed 2 ;-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
There's no guarantee that any particular project will even exit incubation. So I don't agree that a bit of code entering incubation is a defacto endorsement by Apache. I thought the whole purpose of the Incubator was to allow potential code time to breathe and its respective community to get some legs behind it. I think submissions should be voted up or down to enter incubation based on whether we think the technology is a fit for Apache. And, personally, I think AJAX is the perfect fit. Let the project succeed or fail on its merits, not because we're waiting for the perfect implementation to fall into our laps. That's my two yen. - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Sunday, January 15, 2006 9:06:50 PM Subject: Re: ajax proposal? On Sat, 7 Jan 2006, Sanjiva Weerawarana wrote: On Thu, 2006-01-05 at 14:36 -0500, Jim Jagielski wrote: On Jan 5, 2006, at 1:38 PM, Sam Ruby wrote: Sanjiva and I have experience with Apache SOAP. Two rewrites later, and there is a thriving community working on Apache Axis2. The goal here is not to crown anything, but to provide the grain of sand that will lead to the production of a pearl. +1; I don't see this as a crowning at all. Bringing something to the ASF immediately raises its profile in the world, and many people look at that as a badge of merit, and will assume that this must be the right way to do things. -- Martin Cooper I am a big +1 on the ASF getting involved with AJAX. Me too. When the time's right, I'll be happy to help sponsor/mentor this project with the idea of heading for an AJAX TLP at some point. Hopefully before graduation we'll get a couple more AJAX projects coming in and getting all married together or co-existing/competing under the same TLP umbrella. Given we have dozens of Webapp frameworks for Java server side, I don't see how the world will end up with less than dozens of AJAX frameworks. First entrant to the new project will not be a guaranteed winner as there will be no single winner. Sanjiva. - 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] -- Andy Clark * Zimbra * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Andrew Clark wrote: I thought the whole purpose of the Incubator was to allow potential code time to breathe and its respective community to get some legs behind it. Yes. People seem to be viewing proposals as if they were ready to leave the Incubator, not just ready to enter it. Personally, I've always felt that if there are ASF Members who are interested in something, we should be trying to enable their efforts to try. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Martin Cooper wrote: I *care* about the quality of what we build here at the ASF. [X] can very easily cause problems when [...] I have no problem with either of the above (redacted) sentences. However, the answer, in my view, is not to wait for X to become perfected elsewhere. Rather, if there is something wrong, and it is here, contribute to fixing it, even if the contributions are just kibbitzing. Even if you don't contribute code, if you raise perfectly valid issues, and they are ignored, that would be an indicator that the project is not right. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Upayavira wrote: Sanjiva Weerawarana wrote: Hopefully before graduation we'll get a couple more AJAX projects coming in and getting all married together or co-existing/competing under the same TLP umbrella. And surely it doesn't make sense to have multiple (potentially competing) AJAX frameworks under the same TLP? Agreed. If multiple AJAX related projects got married, to use Sanjiva's turn of phrase, that would be fine. But competing projects under the same TLP would rarely make sense, since a TLP should be one community. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/16/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Martin Cooper wrote: I *care* about the quality of what we build here at the ASF. [X] can very easily cause problems when [...] I have no problem with either of the above (redacted) sentences. However, the answer, in my view, is not to wait for X to become perfected elsewhere. Rather, if there is something wrong, and it is here, contribute to fixing it, even if the contributions are just kibbitzing. Which is exactly what I've been doing over in MyFaces-land, by explaining (or trying to explain, anyway) the issues with the use of Prototype in the MyFaces ecosystem. I'm not a MyFaces committer, and I don't even use JSF, but I'm still trying to help. As for whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) -- Martin Cooper Even if you don't contribute code, if you raise perfectly valid issues, and they are ignored, that would be an indicator that the project is not right. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Martin Cooper wrote: Noel J. Bergman [EMAIL PROTECTED] wrote: I don't believe that the ASF should be a place for crowning staid and mature projects. I would like to see continued innovation here, too. I agree with you. Unfortunately, from what I've seen from looking at Zimbra, it's more like the first generation way of doing DHTML frameworks. I'd prefer not to have that become the de facto standard These are fair points, but as I've said in some other e-mails today, why are they fatal, rather than things that can be addressed during Incubation? Are you saying that the community is fatally flawed and cannot evolve? Isn't that a bit like saying that we should reject Struts because JSF is the newer, better way, and we don't believe that the Struts community can evolve outside their box? FWIW, if one of the Zimbra folks is out there reading these messages, I would like to see some sort of technical response to some of the concerns that have been raised regarding the current Zimbra approach, and where the overall AJAX technology appears to be evolving. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
I'd be very happy to have a discussion on technical points as well. regards, Martin On 1/16/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Martin Cooper wrote: Noel J. Bergman [EMAIL PROTECTED] wrote: I don't believe that the ASF should be a place for crowning staid and mature projects. I would like to see continued innovation here, too. I agree with you. Unfortunately, from what I've seen from looking at Zimbra, it's more like the first generation way of doing DHTML frameworks. I'd prefer not to have that become the de facto standard These are fair points, but as I've said in some other e-mails today, why are they fatal, rather than things that can be addressed during Incubation? Are you saying that the community is fatally flawed and cannot evolve? Isn't that a bit like saying that we should reject Struts because JSF is the newer, better way, and we don't believe that the Struts community can evolve outside their box? FWIW, if one of the Zimbra folks is out there reading these messages, I would like to see some sort of technical response to some of the concerns that have been raised regarding the current Zimbra approach, and where the overall AJAX technology appears to be evolving. --- Noel - 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: ajax proposal?
Martin Cooper wrote: whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) If you take your comment to a conclusion, you could be saying that if you don't have time to contribute here, the project should be rejected. Yes, I agree that I've reduced your comment to the absurd conclusion, and one which you most certainly did not intend. But what is a solution? You appear to be against trying to incubate the project because of its current architecture, others appear to want to try. Do we accept it because they want it give it a try, or reject it without trying because you don't have time to help fix it? I'll note that although I'm not familar with Zimbra, there is another proposed project for the Incubator that I am familar with, due to working with another project that uses it, and I seriously dislike it (I'd never use it). Yes, I'm being intentionally vague, because I don't want to prejudice it, and there are other people quite keen to incubate the project. FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/16/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Martin Cooper wrote: whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) If you take your comment to a conclusion, you could be saying that if you don't have time to contribute here, the project should be rejected. Yes, I agree that I've reduced your comment to the absurd conclusion, and one which you most certainly did not intend. Correct, I did not. The only reason I made that comment at all was because it wasn't clear to me whether your earlier comment, encouraging me to contribute to fixing it, was in reference to the use of Prototype in MyFaces or to a potential redesign of the Zimbra code, so I chose to address both. But what is a solution? You appear to be against trying to incubate the project because of its current architecture, others appear to want to try. Do we accept it because they want it give it a try, or reject it without trying because you don't have time to help fix it? I'll take that as rhetorical. But I'd be curious to know how many of those who have expressed an interest in incubating Zimbra, other than the Zimbra folks themselves, are JavaScript developers planning on contributing to the code base, versus people who just think having an AJAX project at the ASF would be cool, and hope other people will do the (coding) work. Clearly I'm a lone voice here, albeit making a fair amount of noise. Given that nobody else seems to share my views on the architecture or on the effect of the ASF brand on the AJAX world, and given that the incubator appears to be a just knock and you're in project anyway, I've assumed pretty much from the get-go that I'm fighting a lost cause here. But that doesn't mean I want to go quietly. -- Martin Cooper I'll note that although I'm not familar with Zimbra, there is another proposed project for the Incubator that I am familar with, due to working with another project that uses it, and I seriously dislike it (I'd never use it). Yes, I'm being intentionally vague, because I don't want to prejudice it, and there are other people quite keen to incubate the project. FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 17.01.2006, at 00:02, Noel J. Bergman wrote: Martin Cooper wrote: whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) ... FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. rantRemember that it's about the community not the code... maybe you should add another bullet to the list at http:// incubator.apache.org/incubation/Incubation_Policy.html to record this new criterion as another entry and/or exit requirement.../rant Seriously, I don't understand why you are talking about code maturity here - IMO this isn't and shouldn't be one of the incubators concerns - you are here to discuss legal stuff, community issues, mentors and the Apache Way, no? Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: ajax proposal?
On Tuesday 17 January 2006 09:18, Erik Abele wrote: Seriously, I don't understand why you are talking about code maturity here - IMO this isn't and shouldn't be one of the incubators concerns - you are here to discuss legal stuff, community issues, mentors and the Apache Way, no? Bingo! Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Erik Abele wrote: Noel J. Bergman wrote: FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. Remember that it's about the community not the code... maybe you should add another bullet to [Incubation_Policy.html] to record this new criterion as another entry and/or exit requirement New criteria? I agree with you that it is about community not code, but that is because we believe that a good community fixes its code. So if someone has strong technical objections to something, and the community is not responsive to them, don't you think that represents a problem? For exit, not for entry. I don't understand why you are talking about code maturity If you mean me specifically, you might want to re-read the context of what I wrote. :-) --- Noel smime.p7s Description: S/MIME cryptographic signature
Re: ajax proposal?
On 17.01.2006, at 03:04, Noel J. Bergman wrote: Erik Abele wrote: Noel J. Bergman wrote: FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. Remember that it's about the community not the code... maybe you should add another bullet to [Incubation_Policy.html] to record this new criterion as another entry and/or exit requirement New criteria? I agree with you that it is about community not code, but that is because we believe that a good community fixes its code. So if someone has strong technical objections to something, and the community is not responsive to them, don't you think that represents a problem? For exit, not for entry. Oh, of course - but for now there's no community yet so he is complaining into the blue sky :) I'd certainly like to see a response to the concerns raised by Martin but OTOH I don't think that it should evolve into a discussion about basic architectural principles or even impact the final consideration of incubation. It's just the initial code, nothing more :) (OK, OK - don't make me think about the IBM PR mentioning the _multi- million_ dollar investment for developing the derby donation.) I don't understand why you are talking about code maturity If you mean me specifically, you might want to re-read the context of what I wrote. :-) Sorry, I think my mail was a bit unclear: I was primarily responding to Martin but I see now why you did mis-interpret my intentions... it's late over here :) Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: ajax proposal?
On 1/16/06, Erik Abele [EMAIL PROTECTED] wrote: On 17.01.2006, at 00:02, Noel J. Bergman wrote: Martin Cooper wrote: whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) ... FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. rantRemember that it's about the community not the code... maybe you should add another bullet to the list at http:// incubator.apache.org/incubation/Incubation_Policy.html to record this new criterion as another entry and/or exit requirement.../rant Seriously, I don't understand why you are talking about code maturity here I'm not talking about code maturity. You might want to re-read the threads. - IMO this isn't and shouldn't be one of the incubators concerns - you are here to discuss legal stuff, community issues, mentors and the Apache Way, no? And the impact of giving a project the ASF brand. And the way the incubator operates as an open door to whoever knocks, with virtually no entry criteria. -- Martin Cooper Cheers, Erik
Re: ajax proposal?
On Thu, 5 Jan 2006, Dirk-Willem van Gulik wrote: On Wed, 4 Jan 2006, Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? .. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or We are part of that market - and I have no illusions about our ability to set standards; we canot; we ONLY seem to do so when we happen to a) to jump on the boat with the right technology and b) get the market to play in our playground. (Marginally helped of course by the fact that so many talented peopel and companies come to play here that we do set the odd's for 'a' and have 'b' causal). If your argument is that the quality of Zimbra code is relatively low; or too immature by itself - and that is why you worry about spoiling the market by betting on the wrong horse - then we should simply reject -this- proposal based on the fact that there is a) not enough quality in the donation and b) no hope for it to improve in our playground. An analogy would be the Java web app environment 5 years ago, when Model 2 frameworks came along and people realised that that was the way things should be done, instead of Model 1. Just as I would not have been in favour of bringing a Model 1 framework to the ASF at that time, I'm not in favour of bringing in what I consider to be a previous-generation JavaScript framework now. Why would we want to perpetuate the old way of doing things? -- Martin Cooper But in general - having the ASF offer it's eco system a place where we all can work on Ajax (and have synergy with all the portal code we have, with MyFaces^H^H^H^H^H^HOurFaces) seems like the right thing to do -when- there are sufficient people interested to work on it. Which is the right validating feedback loop. Dw. - 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: ajax proposal?
On Thu, 5 Jan 2006, Martin Marinschek wrote: We could of course also set-up quality standards which have to be fullfilled before the project _leaves_ incubation. That's a good bar to set... As the name MyFaces has been mentioned quite a bit, I'll explain our situation. We currently use the prototype framework (one of the widely used projects in the market, which Martin Cooper by the way doesn't like either, due to namespacing issues). So, if Zimbra has the same problems, we don't really have a need for the library. Whether I like Prototype or not isn't really the point. The point is that I *care* about the quality of what we build here at the ASF. Prototype can very easily cause problems when combined with other JavaScript code, and this situation is even worse in a portlet environment, so I simply want to make sure that the MyFaces team isn't setting itself up for problems by relying on it. -- Martin Cooper We are hoping for a major donation regarding javascript with ADF Faces - haven't had any chance to look on the sourcecode so far, though. Maybe this will settle all our javascript needs and we'll stop looking out for anything else. regards, Martin On 1/5/06, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: On Wed, 4 Jan 2006, Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? .. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or We are part of that market - and I have no illusions about our ability to set standards; we canot; we ONLY seem to do so when we happen to a) to jump on the boat with the right technology and b) get the market to play in our playground. (Marginally helped of course by the fact that so many talented peopel and companies come to play here that we do set the odd's for 'a' and have 'b' causal). If your argument is that the quality of Zimbra code is relatively low; or too immature by itself - and that is why you worry about spoiling the market by betting on the wrong horse - then we should simply reject -this- proposal based on the fact that there is a) not enough quality in the donation and b) no hope for it to improve in our playground. But in general - having the ASF offer it's eco system a place where we all can work on Ajax (and have synergy with all the portal code we have, with MyFaces^H^H^H^H^H^HOurFaces) seems like the right thing to do -when- there are sufficient people interested to work on it. Which is the right validating feedback loop. Dw. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Thu, 5 Jan 2006, Jim Jagielski wrote: On Jan 5, 2006, at 1:38 PM, Sam Ruby wrote: Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Once we have had a chance to digest all the input and finish dotting the I's and crossing the T's from a legal perspective, Adam or I will come back to ask for a vote. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) Sanjiva and I have experience with Apache SOAP. Two rewrites later, and there is a thriving community working on Apache Axis2. The goal here is not to crown anything, but to provide the grain of sand that will lead to the production of a pearl. I am a big +1 on the ASF getting involved with AJAX. Oh, I am too. I'd just prefer to start off on the right foot. -- Martin Cooper - 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: ajax proposal?
Sanjiva Weerawarana wrote: On Thu, 2006-01-05 at 14:36 -0500, Jim Jagielski wrote: On Jan 5, 2006, at 1:38 PM, Sam Ruby wrote: Sanjiva and I have experience with Apache SOAP. Two rewrites later, and there is a thriving community working on Apache Axis2. The goal here is not to crown anything, but to provide the grain of sand that will lead to the production of a pearl. +1; I don't see this as a crowning at all. I am a big +1 on the ASF getting involved with AJAX. Me too. When the time's right, I'll be happy to help sponsor/mentor this project with the idea of heading for an AJAX TLP at some point. Hopefully before graduation we'll get a couple more AJAX projects coming in and getting all married together or co-existing/competing under the same TLP umbrella. Given we have dozens of Webapp frameworks for Java server side, I don't see how the world will end up with less than dozens of AJAX frameworks. First entrant to the new project will not be a guaranteed winner as there will be no single winner. And surely it doesn't make sense to have multiple (potentially competing) AJAX frameworks under the same TLP? As an analogy, Cocoon and Struts in the same TLP would strike me as somewhat odd. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Thu, 2006-01-05 at 14:36 -0500, Jim Jagielski wrote: On Jan 5, 2006, at 1:38 PM, Sam Ruby wrote: Sanjiva and I have experience with Apache SOAP. Two rewrites later, and there is a thriving community working on Apache Axis2. The goal here is not to crown anything, but to provide the grain of sand that will lead to the production of a pearl. +1; I don't see this as a crowning at all. I am a big +1 on the ASF getting involved with AJAX. Me too. When the time's right, I'll be happy to help sponsor/mentor this project with the idea of heading for an AJAX TLP at some point. Hopefully before graduation we'll get a couple more AJAX projects coming in and getting all married together or co-existing/competing under the same TLP umbrella. Given we have dozens of Webapp frameworks for Java server side, I don't see how the world will end up with less than dozens of AJAX frameworks. First entrant to the new project will not be a guaranteed winner as there will be no single winner. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Wed, 4 Jan 2006, Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? .. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or We are part of that market - and I have no illusions about our ability to set standards; we canot; we ONLY seem to do so when we happen to a) to jump on the boat with the right technology and b) get the market to play in our playground. (Marginally helped of course by the fact that so many talented peopel and companies come to play here that we do set the odd's for 'a' and have 'b' causal). If your argument is that the quality of Zimbra code is relatively low; or too immature by itself - and that is why you worry about spoiling the market by betting on the wrong horse - then we should simply reject -this- proposal based on the fact that there is a) not enough quality in the donation and b) no hope for it to improve in our playground. But in general - having the ASF offer it's eco system a place where we all can work on Ajax (and have synergy with all the portal code we have, with MyFaces^H^H^H^H^H^HOurFaces) seems like the right thing to do -when- there are sufficient people interested to work on it. Which is the right validating feedback loop. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
We could of course also set-up quality standards which have to be fullfilled before the project _leaves_ incubation. That's a good bar to set... As the name MyFaces has been mentioned quite a bit, I'll explain our situation. We currently use the prototype framework (one of the widely used projects in the market, which Martin Cooper by the way doesn't like either, due to namespacing issues). So, if Zimbra has the same problems, we don't really have a need for the library. We are hoping for a major donation regarding javascript with ADF Faces - haven't had any chance to look on the sourcecode so far, though. Maybe this will settle all our javascript needs and we'll stop looking out for anything else. regards, Martin On 1/5/06, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: On Wed, 4 Jan 2006, Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? .. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or We are part of that market - and I have no illusions about our ability to set standards; we canot; we ONLY seem to do so when we happen to a) to jump on the boat with the right technology and b) get the market to play in our playground. (Marginally helped of course by the fact that so many talented peopel and companies come to play here that we do set the odd's for 'a' and have 'b' causal). If your argument is that the quality of Zimbra code is relatively low; or too immature by itself - and that is why you worry about spoiling the market by betting on the wrong horse - then we should simply reject -this- proposal based on the fact that there is a) not enough quality in the donation and b) no hope for it to improve in our playground. But in general - having the ASF offer it's eco system a place where we all can work on Ajax (and have synergy with all the portal code we have, with MyFaces^H^H^H^H^H^HOurFaces) seems like the right thing to do -when- there are sufficient people interested to work on it. Which is the right validating feedback loop. Dw. - 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: ajax proposal?
Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Once we have had a chance to digest all the input and finish dotting the I's and crossing the T's from a legal perspective, Adam or I will come back to ask for a vote. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) Sanjiva and I have experience with Apache SOAP. Two rewrites later, and there is a thriving community working on Apache Axis2. The goal here is not to crown anything, but to provide the grain of sand that will lead to the production of a pearl. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Jan 5, 2006, at 1:38 PM, Sam Ruby wrote: Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Once we have had a chance to digest all the input and finish dotting the I's and crossing the T's from a legal perspective, Adam or I will come back to ask for a vote. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) Sanjiva and I have experience with Apache SOAP. Two rewrites later, and there is a thriving community working on Apache Axis2. The goal here is not to crown anything, but to provide the grain of sand that will lead to the production of a pearl. I am a big +1 on the ASF getting involved with AJAX. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ajax proposal?
So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
--On January 5, 2006 4:32:46 AM +0600 Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? Noe one has called for a vote. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) -- Martin Cooper Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) I am confused - why can't there be multiple ajax projects at somepoint? As the perlers say, there is more than one way to do things. See my note in a previous thread about multiple web app frameworks, etc, etc[1]. - Dan 1. http://mail-archives.apache.org/mod_mbox/incubator-general/200512.mbox/[EMAIL PROTECTED] -- Martin Cooper Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ajax proposal?
Dan Diephouse wrote: Martin Cooper wrote: Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I am confused - why can't there be multiple ajax projects at somepoint? No reason. Martin expressed his personal view. Personally, I disagree with his view. I don't believe that the ASF should be a place for crowning staid and mature projects. I would like to see continued innovation here, too. AJAX is an interesting area, with potential impact for Portals, WS, MyFaces, and elsewhere. Last Fall, we had someone wanting to contribute a JavaScript version of LOG4J, and nowhere to go. An AJAX project would have provided a natural home. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/4/06, Dan Diephouse [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) I am confused - why can't there be multiple ajax projects at somepoint? I don't recall saying there could not. What I am saying is that, were one to come here now, it would rapidly become the de facto standard simply by virtue of being here at the ASF. And once there is a de facto standard, many people won't even bother to look elsewhere, or bother to evaluate its merits or lack of them, because they've already got license, so to speak, to use ASF software. In fact, if we have to have Zimbra here, I would be right with you in hoping something better turns up sooner rather than later. ;-) -- Martin Cooper As the perlers say, there is more than one way to do things. See my note in a previous thread about multiple web app frameworks, etc, etc[1]. - Dan 1. http://mail-archives.apache.org/mod_mbox/incubator-general/200512.mbox/[EMAIL PROTECTED] -- Martin Cooper Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/4/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Dan Diephouse wrote: Martin Cooper wrote: Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I am confused - why can't there be multiple ajax projects at somepoint? No reason. Martin expressed his personal view. Personally, I disagree with his view. I don't believe that the ASF should be a place for crowning staid and mature projects. I would like to see continued innovation here, too. I agree with you. Unfortunately, from what I've seen from looking at Zimbra, it's more like the first generation way of doing DHTML frameworks. I'd prefer not to have that become the de facto standard, and have the ASF innovate in the wide open playing field of the next generation frameworks that are out there now. Yes - let's innovate! AJAX is an interesting area, with potential impact for Portals, WS, MyFaces, and elsewhere. Last Fall, we had someone wanting to contribute a JavaScript version of LOG4J, and nowhere to go. An AJAX project would have provided a natural home. It might have provided a sponsoring PMC, but it's not at all obvious that it would have provided a natural home. Just because they're both written in JavaScript doesn't mean they have any more in common than that. Jakarta for JavaScript? ;-) But yes, AJAX, or more generally, DHTML, is definitely an interesting area. In addition to the projects you mention above, Struts, Tapestry, Cocoon and Jakarta Commons are all working in this area (and all of those are looking at, or already using, next-generation AJAX frameworks). -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
