Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!hoptoad!ptsfa!pyramid!decwrl!ucbvax!rutgers!topaz.rutgers.edu!brandx.rutgers.edu!webber
From: webber@brandx.rutgers.edu.UUCP
Newsgroups: alt.hypertext
Subject: Re: Hypertext Usenet
Message-ID: <560@brandx.rutgers.edu>
Date: Sun, 8-Nov-87 20:48:11 EST
Article-I.D.: brandx.560
Posted: Sun Nov  8 20:48:11 1987
Date-Received: Mon, 9-Nov-87 06:38:46 EST
References: <3296@hoptoad.uucp> <557@brandx.rutgers.edu> <234@papaya.bbn.com>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 52

In article <234@papaya.bbn.com>, rsalz@bbn.com (Rich Salz) writes:
> ] Each site archives all its messages on magtape, e.g.  Then others could
> ] ask them for a copy of that magtape.  "A catalog of sites that are keeping
> ] archives and what sites they are archiving then becomes our equivalent to
> ] the library Serials List and the whole system is our ``inter-library loan.''"
> Cute idea, but needs more infra-structure.  I could see every junior
> hacker sending away to mimsy in order to get the complete words of "Chris
> Torek on BSD" -- completely overloading that site with hundreds of
> requests, each of which is "reasonable" in and of itself.  As anyone who's
> done a non-commercial software distribution can tell you, this kind of
> thing rapidly becomes a big hassle.

First, in order to request CWOCTOBSD they would have to know all the
message-id's relevant, which should slow down the requests a tad bit :-)

Second, while we sit around designing the ideal system, mimsy is
expiring messages as fast as chris can write them.

Third, clearly requests are handled when convenient for the site.  One could
easily set up a standard form, such as ``send Message-ID: <.....>'' as
subject line (reminescent of netlib).  When enough requests pile up
(or someone has time) a tape gets mounted, the requests sorted by id number
to minimize rewinds and the requests handled automatically.  Bounce-backs 
from ``postmaster'' will probably always be the biggest problem -- I wonder
how the netlib people handle it.

> Ahh, one big machine to serve the world?  You mean like Multics, which was
> to serve the entire Boston/Cambridge community?  The problem the

I didn't say it was easy, only easier.

> nameserver folks (users and maintainers) are having is that the system is
> just not big/fast enough.  Not many people think the basic concept is
> broken.  

Depends on what you think the ``basic concept'' is.  Their current
algorithms corrupt their own database leading to some rather quaint
problems.  Word is they are doing a complete rewrite.

> Unless you complete control over growth (does anyone ever have
> complete control over growth), you had best lay your groundwork to allow
> distributed mechanisms otherwise your system is guaranteed to become
> insufficient at some point.

Perhaps, but it doesn't mean that it is an approach that is currently
technically feasible.  Writing a distributed database is much like
writing an operating system.  Would you want to write an operating system
for a machine whose communication with its disk is as faulty as a
uucp link and whose disks were as varied as Usenet sites (each of
which to be managed by a different person)?

---------- BOB (webber@aramis.rutgers.edu ; rutgers!aramis.rutgers.edu!webber)