"
Please note that my support is based on the following assumptions:
1. all spec/seed code will be released (this, in my opinion, must be done prior to consideration) If thats not till March, then the project can't reasonably be considered until March. (We don't take on other closed source projects)
2. David Taylor and the other committee members will soon be released from the Non-Disclosure agreements they are currently under so that they can participate freely. (You can't have a community based on a closed spec where the members can't speak freely).
3. I'm assuming that others including from the Jetspeed and Cocoon-portal will go add themselves as committers... http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal - I will send an invitation out.
4. The project will keep compatibilty with the spec but we'll be free to expand beyond it in much the same way Tomcat and other projects do. Xerces, for instance, doesn't solely implement just SAX and JAXP with a parser under it. From a performance standpoint, SAX interfaces would be nice, having them in the RI (extending the spec) would serve this purpose.
5. Future revisions of the Spec will happen in the open.
Please note, I REALLY want to see this at Apache, so this is not a fillibuster intended to kill the effort to be followed by a series of Catch-22 arguments (here, but not there, which means it can't be here). But I don't feel the participants should be given a free pass into Apache to create non community-based non-open projects just to get the feather. If this is going to be an Apache project, it does need to be an Apache project. If there is motivation on everyone's part, we CAN obviously fix these issues by addressing them head-on in an honest and straightforward manner.
I DO want to particpate, and I DO want to see this happen, but lets do the community thing. We can certainly resolve these issues if all parties are motivated.
-AndrewCOliver
"
I've also posted them here: http://nagoya.apache.org/wiki/apachewiki.cgi?TalkPlutoProposal
-Andy
Steven,
I think these are exactly the sort of questions incubator is designed to answer. Tapestry was about seeing how an existing project can come into Apache. Perhaps Pluto is an opportunity to understand how a new project can be created and encouraged at Apache. They are both interesting challenges for the incubator.
As for your issues, "No code" is true (for now) but that is the sort of project Pluto represents. If at the end, the incubator PMC decides that the project still has the problems you identify (if they are in fact problems), then the project should remain in incubation until the community is self supporting, or be discontinued, whatever. That is a decision for further down the track, I think.It would seem to me that if JetSpeed is in scope for Jakarta,
IMHO, a reference implementation at Apache of a Portal standard would be appropriate, especially considering JetSpeed is already at Jakarta. I'm not into portals myself so I can't really comment on the project's merits beyond that.
Conor
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
