RE: Finding the arbiter (was RE: proposed additions for discovery , sorting, and typed values)

I'll have to agree on your comment about finding the arbiter. Even for the
non-dasl cases: "where is our department's website?", "where is my
<insert-protocol-here> server", etc., the user is typically told the magic
information that works but doesn't use the protocol itself to discover it.

Likewise, I agree that a common case ( *the* common case, I would imagine)
is that a server that supports DASL will simply support it across every URI
it owns. However, a minimum discoverability mechanism here could be even
more simple -- the client can invoke SEARCH against any URI that is at hand
or against "/". That is, I believe that the common case doesn't need much
discoverability above what is already provided in HTTP. For a typical
server, an arbiter property on a resource for the common case would probably
list the parent container or "/" -- exactly those URLs the client can
already guess at. Of course, for more complex scenarios, then I agree that
discovering the arbiters can be much more useful.

Another question to ponder: what's the difference between discovering
arbiters and being redirected on a search? Aren't these the same thing? If
so, then solving a search redirection might be the way to discover arbiters
for the more complex cases. 

-Saveen



-----Original Message-----
From: Jim Davis [mailto:jdavis@parc.xerox.com]
Sent: Monday, March 16, 1998 12:15 PM
To: www-webdav-dasl@w3.org
Subject: Finding the arbiter (was RE: proposed additions for discovery,
sorting, and typed values)


At 11:18 AM 3/16/98 PST, Saveen Reddy (Exchange) wrote:
>There's a particular case in which I'm interested here. Suppose a server
>offers searching on every resource -- making it easy for the client to
>perform searches, by essentially making every URI available as a search
>arbiter. In this case clients don't have to go find an arbiter -- they can
>whatever URI is at hand. 

This raises a point that applies to DASL as a whole not just my proposals,
so I am elevating it to a separate reply, namely how can one discover the
query arbiter for an arbitrary URI.

That is, you have a URI (http://foo.com/rumors/) you want to search.  How
do you find the arbiter?  

Saveen's example has the client just knowing (somehow) to send the search
to foo.com/rumors/

I think the answer in the general case is that you can't discover this.
Consider Web crawlers, e.g. Lycos may index (be an arbiter for) foo.com,
but foo.com doesn't know this and no property of any resource at foo.com
can tell you to use Lycos as an arbiter, unless both Lycos and foo.com
cooperate.  So it's impossible in general.

However it will often be the case that the URIs can know the location of at
least one arbiter (e.g. if foo.com supports DASL for it's own contents),
and in this case it can be specified by a property on the URI.

I propose we define a new property arbiters which holds a list of href each
element of which is a URI of a query arbiter (believed to) be able to
search the resource.

Received on Wednesday, 25 March 1998 14:47:30 UTC