multiple URI elements per Service in XRDs
Johannes Ernst
jernst+lists.danga.com at netmesh.us
Thu Jan 19 00:35:28 UTC 2006
This question is really for the XRI guys whose XRD/S format/subset we
are using for YADIS. Fortunately, some of you (you know who you are!)
do seem to monitor this list ...
The question is: is it really necessary to allow multiple URI
elements within the same XRD element?
My understanding is that this is about availability and load
balancing: "If this URI does not work, try that one, it provides the
same service", that kind of thing.
First, there is a question whether load balancing and availability
should not be handled on a lower level -- Cisco routers are good at
that, hiding all of the complexity behind a simple URL.
But even if it isn't handled on a lower level, couldn't I just simply
express the exact same thing with only one URI element per XRD, but
having multiple XRD elements (with the same type and whatever other
data is carried around) and the same priority?
This would very substantially reduce the processing needed by the
receiver of the document (such as a YADIS Relying Party). For
example, if with the current spec, I want to determine whether or not
a given identity URL supports, say, LID VCard queries and with which
URI to perform the query, it appears I have to do this:
- select all XRD elements that have a child with the "LID VCard
query" type.
- order the found XRD elements by the priority attribute
- if there is only one highest-priority element, select a URI at
random contained in that XRD element, try it and keep trying the
others in the same XRD element. If none work, go to the next-highest
priority element
- if there are N>1 highest-priority elements, select an XRD element
from that set at random, and try the first URI from that element. If
it doesn't work, go to the first URI from the second element in that
set. Then go to next XRD, until end of set, then go to second URI in
first XRD and so forth. Keep track which we've tried already. If
there are no more from that set, go to next-highest priority XRD.
This is all doable, no question ... but is the additional algorithmic
complexity, and in particular the tracking part, perhaps across
requests and sessions and XRD types ("I already know this URI does
not work") commensurate with the benefits?
Johannes Ernst
NetMesh Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060118/0e0fff67/lid.gif
-------------- next part --------------
http://netmesh.info/jernst
More information about the yadis
mailing list