W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: PEP Battle Plan [rexmit, garbled]

From: Keith Moore <moore@cs.utk.edu>
Date: Sat, 19 Oct 1996 18:13:18 -0400
Message-Id: <199610192213.SAA23882@ig.cs.utk.edu>
To: Rich Salz <rsalz@osf.org>
Cc: moore@cs.utk.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, khare@w3.org
> >Close, but not quite.  A resolution service, not a directory service.
> >
> >(Where by "directory" I mean something that can do content-based
> >searching.)
> 
> By directory, I mean attribute-based searching.  That seems to be both
> the past (X.500), the would-be future (XFN), and the fad-of-the-moment (LDAP).

There's nothing wrong with having attribute-based searching, but
it's better if it's viewed as layered on top of a name-resolution
substrate. One reason for this is that much of the time
you don't need to do a search; having the two layers separated
enhances the scalability of the system.  Another reason is that
the most effective search engines are specific to a subject domain,
rather than generic.  So we need a single, generic, distributed 
document store as a substrate for both generic and domain specific
resource discovery tools.

Of course, if some providers want to provide attribute-based
searching, co-locate the two services, and even return name resolution 
information along with the response to a directory query, that's fine 
-- as long as there's a well-defined standard for doing the name
resolution by itself.
 
> But the latter is where the world is going.  

No offense, but I've heard the official wisdom about the future
of the world so many times that ... well, I'm skeptical.

Relatively simple solutions to problems, which fit in well with
the existing infrastructure, offered at the right time,
seem to be the best way to acheive success.

In this case, I'm talking about ~10000 lines of code for each of
server and client glue, not counting the rpc and db libraries.
(actually, the current implementation of RCDS is ~4000 lines in
the server, 2500 lines in the client, and 3300 lines of common
code...but of course it will have to grow somewhat)

Which is not to say that there's no need for attribute-
based searching, it's just not what I'm talking about here.

(Actually, this discussion probably belongs on the URI mailing list.)

-Keith
Received on Saturday, 19 October 1996 15:14:04 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:15 EDT