[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata
From: |
Paul Snively |
Subject: |
Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata |
Date: |
Wed, 17 Sep 2003 07:41:10 -0700 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday, September 17, 2003, at 06:26 AM, Stephen J. Turnbull
wrote:
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?
This is a big part of what I'm driving at: arch (rightly, IMHO)
enforces a nice, regular naming convention, at the cost of being
somewhat unforgiving of mistakes and somewhat verbose. The less
remember-and-type here, the better.
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.
It's really leveraging a well-known service that we all expect to be
there anyway: DNS. (So far in this discussion, I've really been
conflating two distinct things, DNS-SD, which doesn't require multicast
but rather only dynamic DNS updating, and mDNS, which is an
implementation of DNS that uses multicast. I'll try to be more precise
from now on.) All DNS-SD really is is a mechanism for registering
services and their locations in a DNS server using plain ol' DNS
records. If you can look stuff up on that DNS server, you can discover
those services. In that sense, the idea really is analogous to the LDAP
registry idea, and apart from not requiring any additional
infrastructure (assuming that you have a DNS server that supports
dynamic updates) there's probably not much benefit to it.
OTOH, when you add mDNS to the picture, it changes significantly: this
gives you infrastructureless support for enough of DNS to do DNS-SD, at
least, on the local link. Anyone with an mDNS responder on their system
now has the ability to lookup registered services on their own machine.
This is the part that won't scale to the Internet (what with the
multicast). But that's a separate issue from whether it's a good idea
to use DNS-SD or not.
So the upshot is: if you use LDAP etc. you need relatively fixed
infrastructure. If you use DNS-SD you can take advantage of relatively
fixed infrastructure, i.e. a DNS server. But you leave open the
possibility of using mDNS in support of DNS-SD and requiring no
infrastructure.
Does that make more sense?
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,
Yeah, this is the unfortunate piece that's come up already.
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.
Yes; it means that the port is a chokepoint of a kind: there can be 0-N
arch repositories behind it. So there's some additional scaffolding
that would have to be done at discovery time to go beyond the "I've
found the FTP/HTTP/... service" to "I've found these arch archives." I
haven't yet put any thought into what this would look like.
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).
This isn't a bad idea, especially for platforms with LDAP already on
them. I'm sure something essentially analogous could be done without
LDAP. As per my other e-mail, though, I'm striving to keep an
infrastructureless solution available, and I took a moment to describe
the relationship between DNS-SD and mDNS in support of that goal.
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.
That's exactly right: the challenge (in my mind) is to let the world
know that there are public arch archives available "here." What "here"
means given that arch is transport agnostic is an interesting question.
How you keep "here" appropriately flexible given that DNS-SD only gets
you to a host and port is another interesting question. Can we answer
these questions, or are we better off looking elsewhere?
Of course. The point is that creativity doesn't scale, a standard (if
carefully designed) might.
Well put. I'm always surprised when people propose essentially social
solutions and expect them not to have unacceptable failure rates. :-)
--
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.
Best regards,
Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iEYEARECAAYFAj9oco4ACgkQugPBK9Deteo0jACfZH68ug/I2r5ykWJJwkBKjd7P
4pQAoN8dRCAFQOF7GJX7XmUo5YfCQ1Vh
=b6SZ
-----END PGP SIGNATURE-----
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, (continued)
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Florian Weimer, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Paul Snively, 2003/09/16
- [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Miles Bader, 2003/09/17
- [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Doran Moppert, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata,
Paul Snively <=
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Tom Lord, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Andrew Suffield, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Robert Collins, 2003/09/20