gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Automatic archive discovery, proposed extension


From: Jan Hudec
Subject: Re: [Gnu-arch-users] Re: Automatic archive discovery, proposed extensions (was: take 1)
Date: Tue, 16 Dec 2003 11:19:45 +0100
User-agent: Mutt/1.5.4i

On Mon, Dec 15, 2003 at 17:24:46 +0000, Andrew Suffield wrote:
> 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.

It's much easier for tla. In tla, it would share common code with
existing implementation. Also it scales better, because the size of
reply is independent of size of the index.

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

Of course it is orthogonal. It's however other issue to resolve.

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

I don't like the idea of client parsing a (potentialy) long file.

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



> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]