On Thursday, Oct 31, 2002, at 19:51 US/Pacific, Ivelin Ivanov wrote:


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.
You can still put a proxy in front of each server, thus effectively having a network of machines hosting Cocoon, each with its own proxy.

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.
How would that be different from obtaining the permission to modify the config file of Apache on the main server of apache.org? The DNS server and the Web server run on the same machine.

Also I wish we could have every day a company willing to allocate hardware resources for hosting Cocoon. In reality, we'll have very few such machines, perhaps only a couple to start with. So the DNS modification process is really a non-issue.

The Apache proxy solution has its own problems, the biggest one being the assumption of a central HTTP server (read single point of failure) which needs to direct the traffic to the backend servers.

The DNS load balancing solution was the easiest solution I came up with, I'm sure more knowledgeable people than me have better solutions.

----- Original Message -----
From: "Ovidiu Predescu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 [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.

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 <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [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]

Reply via email to