Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <003401c2815a$0707b2e0$0100a8c0@MAUCHI>
From: "Ivelin Ivanov" <ivelin@apache.org>
To: <cocoon-dev@xml.apache.org>
References: <983EB4BA-ED2B-11D6-814C-00039398D61E@cup.hp.com>
Subject: Re: [important proposal] Cocoon as official Apache project
Date: Thu, 31 Oct 2002 21:51:57 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


Advantages to the Apache reverse proxy solution is that
1) Many Cocoon pages can be cached, incurring much lighter load on the
actual application servers. Also if there is a temporary downtime for the
app server, visitors are likely to see at least the top level site pages.

2) It is much easier to modify an apache config file, then it is to modify a
DNS table. I don't mean editing the files, but the process it involves to
obtain permission for modification.


Ivelin


----- Original Message -----
From: "Ovidiu Predescu" <ovidiu@cup.hp.com>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, October 31, 2002 5:50 PM
Subject: Re: [important proposal] Cocoon as official Apache project


>
> On Thursday, Oct 31, 2002, at 14:07 US/Pacific, Sylvain Wallez wrote:
>
> > Steven Noels wrote:
> >
> >> 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 infrastructure@apache.org.
> >>
> >> 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.
> >
> >
> > I like this idea, as we need, as shown by cocoondev.org, to host some
> > live Cocoon apps. But we *must* also use the common infrastructure
> > provided by daedalus and icarus when it makes sense : static website,
> > distros, mailing lists and cvs (IMHO including the ones of
> > cocoondev.org). This ensures we won't be tempted by a "Cocoon software
> > foundation" (even if I'm sure Stefano will take great care to avoid
> > this), save bandwidth, CPU and administration costs for
> > people/entities offering resource for live applications.
> >
> > Proxypassing will also allow to have _several_ machines behind
> > cocoon.apache.org. This can provide simple load partitioning and allow
> > different members of the community to offer CPU and bandwidth (nothing
> > sure for now, but I'd like my company to offer some).
> >
> > However, I wonder if proxypassing from San Diego (IIRC this is where
> > icarus and daedalus are) to Ghent or another european location is
> > technically ok ? Don't you fear about tcp packets making a trip around
> > the earth when you send a request through cocoon.apache.org to the
> > machine that's in the room next door ?
>
> There's no need for proxying via HTTP, we can solve the problem a lot
> easier from DNS. Just change the main DNS at apache.org point to the IP
> address of the machine which hosts cocoondev.org and we're set. If need
> be to do load balancing, we can do that from DNS as well using a simple
> rotating DNS policy. If other companies want to support it, we can
> simply add their machines to the DNS pool.
>
> The point is we need a machine to host live Cocoon instances, most
> likely the machines at collab.net will not have the resources to do it.
> We need other machine(s) for this task, and since Steven and
> outerthought have already thrown hardware and money at it why not use
> them?
>
> Greetings,
> --
> Ovidiu Predescu <ovidiu@apache.org>
> http://webweavertech.com/ovidiu/weblog/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org