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

[Andrew Suffield]

On Mon, Dec 15, 2003 at 02:47:49PM +0100, Jan Hudec wrote:
> 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").

This seems pointless, and just makes it harder to work with.

> 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".

This is (deliberately) orthogonal. It's really easy to generate an
archive-list file automatically, from a CGI script or whatever (I was
figuring an email interface, but not worrying about it too much). For
now, I'm concentrating on the client interface; the update process
should be obvious once the client interface is complete.

> 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.

This is far too inflexible; there's no even theoretically possible way
to have a regexp match in the list (ignoring more immediate concerns,
that's a good rule of thumb for whether or not any given query scheme
is sufficiently flexible).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature