Message-Id: <199710160925.LAA13675@zafir.dc.luth.se>
To: Brian Behlendorf <brian@hyperreal.org>
cc: mirrors@apache.org, Goran.Oberg@dc.luth.se
Subject: Re: CVSup 
In-reply-to: Your message of "Wed, 15 Oct 1997 00:40:59 PDT."
             <3.0.3.32.19971015004059.0097fd20@hyperreal.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 Oct 1997 11:25:12 +0200
From: Goran Oberg <goggi@dc.luth.se>
Sender: mirrors-owner@apache.org
Precedence: bulk

> Now that apache.org is a FreeBSD box, we are beginning to explore using=
 a
> program called "cvsup".  Its basis is a program called "sup", which
> essentially works as a remote-file-synchronization program; it allows a=

> site to maintain a mirror of a remote file tree in a very efficient man=
ner.
>  "cvsup" is an extension of this to use a CVS tree (when it exists) to
> allow for "diffs" to be sent when a file changes, rather than resending=
 the
> whole file.  Thus, all in all it would be a more bandwidth-efficient me=
thod
> of updating one of your mirror sites from the source.

I would like to suggest we might make better use of the resources already=

available and in place instead of searching for new ways to improve the
transport to the mirrors of www.apache.org.

One example of this is the recent newcomers perl.apache.org and
java.apache.org. The current links on www.apache.org and more importantly=

on its mirrors point to the central servers even though the links could b=
e
local to that server to ease the load on the central server and give
users quicker responses.

Perhaps the fact that the full perl.apache.org and java.apache.org seems =
to
be mirrored for no or little use is only temporary. You might be planning=

to set them us up us truly seperate servers be able to take a larger load=

on these now virtual servers. But the foreseen need of doing that could
become a self-fulfilling prophecy if you lead all requests back to the
central server instead of letting the network of mirrors cope with the
load. Of course I'm only speculating, both about your motives for
centralizing the perl- and java-info and the effects of different
solutions.

Therefore I suggest that the links in /related_projects.html points to th=
e
relative URLs /perl/ and /java/ instead of forcing the user back to the
central servers at apache.org.


Just my $0.02.


Wkr

/G

-- =

 G=F6ran =D6berg <goggi@dc.luth.se>        <URL:http://www.luth.se/~goggi=
/>
 Computer Support Center                       Adm./CoAdm. of
 Lule=E5 University, SWEDEN         {www,proxy,{www,apache}.dc,ftp}.luth.=
se
_________________________________________________________________________=