multiple URI elements per Service in XRDs

[Peter Davis]

On 1/19/2006 1:48 PM, "Johannes Ernst" <jernst+lists.danga.com at netmesh.us>
wrote:

> Thanks for the response ... comments in-lined.
> 
>> Assuming s/XRD/Service/g:
> 
> I'm shocked, shocked to find that there are geeks on this list! --
> Your winnings, sir. -- Thank you very much.

:-)

> 
>> There are many motivations for supporting multiple URIs for a service:
>> - convey multiple URI encodings (eg URI vs IRI).  Esp in the near
>> term, some
>> applications will not be able operate on IRIs
>> 
>> - convey multiple URI schemes, eg FTP HTTP HTTPS URN MAILTO GOPHER
>> (heh,
>> yeah there are still gopher servers out there!!) etc etc...  This
>> is perhaps
>> the most important motivation, IMHO
>> 
>> - load distribution, etc...
>> 
>> It's likely, at least for YADIS, you'll have at least 2 (HTTP and
>> HTTPS)
> 
> Yes, but will they truly be on the same service? It appears to me
> that if I have a choice of doing the same thing via HTTP and HTTPS,
> I'd have a preference which one should be used, and thus they would
> be in different service elements with different priority attributes?

A service is defined by some specification somewhere, which provides the
corresponding processing semantics for what to do at the <URL/>.  A service
may be bound to any number of transports (which is generally associated with
a URI scheme... Tho not always).  HTTP and HTTPS are roughly equivelent with
only the addition of requiring the use of a different (lower) transport
layer.  The application protocol HTTP is mainly unchanged.

I see these as two different endpoints of the same service.

Others have commented well on additional use cases.

> 
> What's really behind my question is that I couldn't really think of
> any YADIS scenarios I would expect to find in the wild, that would
> take advantage of all the machinery. (It may be different for XRI, I
> can believe that).

I suppose.  Yadis can specify a constraint on the URI frequency, but I think
that is unnecessary, and perhaps in the future, unfortunate.  Remember that
the expectation is that once deployed, the specs underneath the application
will not change (or will do so slowly, with low frequency).

=peterd  (http://public.xdi.org/=peterd)