Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata

[Stephen J. Turnbull]

>>>>> "Doran" == Doran Moppert <address@hidden> writes:

    Doran> On Tue, Sep 16, 2003 at 09:43:13PM -0700, Paul Snively
    Doran> wrote:

    >> I think there's some tipping point: you can comfortably do
    >> manual registration of some known public archive for scales of
    >> up to a couple of dozen people. At the scale of a major
    >> conference, however, that becomes problematic and DNS-SD/mDNS
    >> become very helpful. On the other

    Doran> How useful, really, is automatic registration of archive
    Doran> names beyond about two dozen anyway? I have 20-odd archives
    Doran> registered and already that's too much to reliably remember
    Doran> without some kind of meta-data (in my case, a text file and
    Doran> ArchiveRegistry on wiki).

Right.  But wouldn't it be more pleasant (not to mention less
typo-prone) to pull your "short-list" from a menu (which could even
suppress the URLs), than to type them in?

    Doran> Really it sounds to me as though you're barking up the
    Doran> wrong tree: it would make more sense to me to have an HTTPD
    Doran> somewhere (which can register itself through DHCP or
    Doran> various DNS hacks - ask Verisign (verisign-must-die.com)
    Doran> about this) with a well-known URL featuring a table similar
    Doran> to ArchiveRegistry.

This is equivalent to what Paul is talking about, except that the
feature that Paul is talking about requires only one well-known "URL"
for discovery of all services, and is optimized for that purpose.

The two big questions I have about Paul's idea is that (1) the RFC
2782 SRV record will not give you a file system path, only a
port---effectively, the service is assumed to be unique on that host,
and (2) not only does arch support multiple transports (this bullet
could easily be dodged simply by defining arch-ftp, arch-http, etc
services), but also it many hosts will want to publish multiple
archives.  This means that problem (1) is inherent.

The obvious way to dodge this is to provide a network service named
"arch-archive-directory" with an arbitrary port, connect to it, and
get a list of arch archives available.  However, something more
general, maybe LDAP, would probably be a better idea.  So the protocol
would be something like

(1) Join the big-conference.acm.org network via DHCP.
(2) Do a SRV query for LDAP in the big-conference.acm.org domain.
(3) If it exists, contact the server and register your archives with
    it (I'm a bit fuzzy on whether this makes sense with LDAP, maybe
    you'd need a more on-line directory service with some kind of
    authentication and real-time database updating, but LDAP allows
    recursive querying of other servers IIRC, so what you'd do is have
    your local LDAP registered with the conference's, and it would do
    the querying to build up its cache).

    Doran> If I'm walking into a conference and I want to
    Doran> auto-publish, I don't think this is arch's job but rather
    Doran> that of the network services on my box.

Right ... and Paul is recommending DNS-SD in particular.  He's not
saying that arch needs to _do_ anything; it just needs to be
"registered" (whatever that means in this context) and ready to answer
the door when you knock.  And it could provide a convenience wrapper
over a more general service directory service.

    Doran> Heck it could probably be done by creative use of a VCard field.

Of course.  The point is that creativity doesn't scale, a standard (if
carefully designed) might.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.