Where is cocoondev.org hosted? Kansas? Ping from Austin, Texas is good: ~30ms.
What are the machines there? CPU, RAM, HDD, OS, etc. Steven probably mentioned that on the cocoondev list already, but I must have missed it. Ivelin ----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Dirk-Willem van Gulik" <[EMAIL PROTECTED]> Sent: Thursday, October 31, 2002 6:07 PM Subject: Re: [important proposal] Cocoon as official Apache project > Steven Noels wrote: > > > Carsten Ziegeler wrote: > > > > > 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. > > > > > > 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 :-) > > > > 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). > > I think that having a machine name detached from any domain name would > help a lot both in communication and in perception of hardware > neutrality. If Nagoya was called 'e4500.sunlabs.org' I think people > would be less friendly to that, don't you think? > > > 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 :-) > > I like that very much! In fact, I was planning to have a transparent > proxy on top of any live cocoon system to reduce its load using > proxy-friendly http headers. > > > > > 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] > > I love it. > > > 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. > > Amen. > > > 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. > > I see no problems with that. > > Just understand that anything that is not contained into a *.apache.org > domain will not be protected by the ASF legal umbrella. So, I like the > parallel between mozilla.org and mozdev.org and I think it would make > sanse to do so here, maybe using cocoondev.org as an incubator for > cocoon-related stuff with greater visibility than simply throwing it > into sourceforge and get lost. > > > > > > 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. > > > > > > 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?). > > I think the legal protection comes from the URL space not from the > actual location of the machine or by who pays the bandwidth. Also note > that php.apache.org redirects to www.php.net which is an official ASF > project (even if many members are not that happy with the way PHP has > managed to have special status, but this is a different story) > > > > > > > > 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. > > > > > > 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 :-) > > Or when people use domain names to refer to machines ;-P > > When you told me privately that you wanted to have cocoondev.org under > the Cocoon PMC and I said 'hmmm, maybe this is too much' and you pissed > off, it was simply because I thought you wanted the Cocoon PMC to > superview a non-ASF web site. See where all this non-explicitness came > from? [not saying this is your fault, but I think that I didn't make > anything implicit] > > To avoid having to explicitly indicating this to *every* ASF individual > we'll have to confront to about this (and there will be a lot, ASF > members tend to be very conservative, expecially about infrastructural > issues), I strongly suggest you give a name to that machine and start > referring to it with that name instead of with the domain name it > currently binds to. > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > -------------------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
