Carsten Ziegeler wrote:
First things first: cocoondev.org is simply a machine name, and it is currently listening to/hosting outerthought.org, forrest.cocoondev.org, and whatever name we could invent for it: the joy of DNS :-)But, *if* Cocoon becomes a top-level project, I'm not sure if it is also a good thing to use cocoondev.org as the infrastructure. Now I see two possible problems:a) What is hosted where? Is a mailing list hosted at apache or at cocoondev.org etc. Of course, this might not be a big thing, but it could confuse others. We could use cocoondev.org for example for show casing Cocoon and everything else is hosted at apache.
So when I say cocoondev.org, I simply mean the machine (and its primary name, which even could be changed if we really would like to).
Technically, I was thinking along these lines: we use cocoondev.org (the machine) to host the new website and the developers community website, which is being ProxyPassed [1] by daedalus or nagoya as cocoon.apache.org. That way, we leverage [2] the existing bandwidth availability and are able to use the lowered load on our (= the cocoon community) own machine for 'cool stuff'. The main website can make use of all dynamic features we would like to use, but with some clever expiry header setting we still can benefit of a reverse proxy, formed by nagoya or daedalus.
[1] http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypass
[2] buzzword bingo: 1 point :-)
Lists for Cocoon-core development should stay at daedalus, as cvs for Cocoon-core should stay at icarus, but maybe, if someone builds a cool webmailarchive using Cocoon, we would be able to run that software on our own machine, without heavy lobbying of 'the powers that be' at [EMAIL PROTECTED]
Mind you that I really appreciate the hardware resources so kindly offered by Collab & Sun, but given the broad range of projects & services they have to support, and the inevitable burden that comes with this, I believe everybody will be better off if we do our own thing ("we" and "our" as in the Cocoon developers community), maybe reverse proxied by nagoya for load & bandwidth purposes.
Along the Cocoon-core website and the possible developers community website (of which the Wiki could be part), there is still space to host other Cocoon-related projects, part of the initial version behind cocoondev.org.
See Ovidiu's remark - those machines aren't necesserally owned by the ASF, I believe - and I'm pretty sure the bandwidth bills are paid by Collab, not by the ASF. The reason for investigating possible official endorsement by the ASF (dunnow how that would look like, but anyhow - maybe http://xml.apache.org/ack.html comes close ;-) is exactly to make sure that eventual legal issues are covered (Dirk?).b) Legal issues. To be honest, I don't know much about legal things, but I guess that it might make a difference if something is done on a server hosted by apache or on a server not hosted by apache.
Yeah, but let's try to use the list so that non-attendees are being informed, too. We've just seen what happens if people don't understand each other because of non-explicit communication :-)Don't get me wrong, I really like the idea of cocoondev.org and as long as Cocoon is not a top-level project, it's the only way. But if we become a top-level project, I really like the idea to "fix the current problems/shortcommings" here at Apache. Perhaps we can talk more about this at the gettogether.
Thanks for your remarks!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
