Re: [Gnu-arch-users] Re: Automatic archive discovery, proposed extensions (was: take 1)

[Jan Hudec]

On Mon, Dec 15, 2003 at 07:16:24 +0000, Andrew Suffield wrote:
> On Sun, Dec 14, 2003 at 04:16:15PM -0800, Tom Lord wrote:
> >     > From: Robert Collins <address@hidden>
> > 
> >     > On Mon, 2003-12-15 at 09:47, Miles Bader wrote:
> >     > > Anyway I have no idea why it's a hard problem, surely a `meta 
> > archive'
> >     > > such as you propose could be a simple text file reached by the
> >     > > meta-archive url, which could have a list of real archives and their
> >     > > URLs.  This shouldn't place any restriction at all on the URLs of 
> > the
> >     > > real archives.
> > 
> >     > Such a text file is precisely what asuffields proposal entails.
> > 
> > The thing I don't like about asuffield's proposal is that it provides
> > auto-registration-on-demand based only on archive name and taking as
> > authoritative a list of name->location mappings that has no obvious
> > connection to the archive's owner.  There's nothing right about that.
> > 
> > I think it aimed to make a kind of built-in-rdist but instead hit the
> > target of poorly-designed-name-authority-for-archives.
> 
> Careful, it's deliberately non-authoritative (unlike, say, DNS);
> everything stems from the root archive list in the user's ~, and is
> trivially overridden.
> 
> In more practical terms, I can think of no way to take an archive name
> and figure out the owner, short of consulting an arbitrary list. They
> just don't embed anything else that's useful. Certainly a system like
> DNS is useless here. What I've thrown together isn't great, but it's
> simple and works and easy to extend; I figure it's as good a starting
> point as any (in the same sense that /etc/hosts is a good starting
> point for host resolution). Better ideas are invited.

It looks quite sane.

I would however modify the format a bit to make it more "in arch
spirit":

1) Repository would be a directory, containing files named like relevant
   archives, or their prefixes (prefix can only be cut at --). That
   would also be the format of "top-level" index. (Yhe last resort might
   be mail domain only, so some organization might have it's own
   repository and not add each member separately to the "master").
2) Each file in a repository might be one of:
    - file containing URL of another repository.
    - file containing URL of the archive.
    - the archive itself (perhaps this is not worth it -- it would mean
      an extra HTTP request).
3) A CGI script should exist to add records and to periodicaly check
   their validity. Only a valid record should ever be added and records
   that no longer seem to work should be removed. Notification should be
   sent to their owners 
    - Record names include email addresses, so the "owner" is clear.
    - For whole-domain records (@domain), the owner should be some
      special mail alias, say "archmaster".

So, say the master repository was on
http://www.gnu.org/software/gnu-arch/ans
and I was looking for archive address@hidden

Tla would first request
http://www.gnu.org/software/gnu-arch/ans/address@hidden

If that was not found, it would fall back to .../ans/address@hidden and
then to .../ans/@emf.net.

If one of them was found, it would first check if the URL in the
response is the desired archive. If yes, it would register it and start
getting content. If not (in the second and third case), it would again
look if it is a directory containing one of address@hidden,
address@hidden or @emf.net and if so, get new URL there etc. until the
archive is reached. (It should either have limited depth or insist on
each subsequent match being more exact than the previous).

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>