RE: [xri] Clarity around Ref processing behavior.

["Steven Churchill" <steven.churchill@xdi.org>]

Victor,

Regarding performance, whether an XRI client (the program asking =andy for a
given service type) uses a local resolver or a proxy resolver is a matter of
configuration. In either case, the latency you speak of would take place in
the resolver, and only in the cases where it doesn't have the requested XRD
already in its cache. Translated: if nothing happens to be cached, then the
requesting XRI client will need to wait longer for the result the first time
the request is made. (As for too much load on proxy resolvers, their CPUs
don't spin while they wait on TCP/IP requests, and, besides, if a proxy
resolver cannot stand the load, then it should be load balanced or it should
not be running in the first place.)

Regarding using Service Refs, these have different semantics than XRD-level
Refs. Service Refs can only be HTTP(S) endpoints; and they do not support
the "if I can't find the service here then follow the Ref" semantics. That
is, they really don't address Andy's use case.

~ Steve



-----Original Message-----
From: Victor Grey 
Sent: Sunday, September 23, 2007 4:18 PM
To: Steven Churchill
Cc: xri@lists.oasis-open.org; andy.dale@ootao.com; 'Kermit Snelson'
Subject: Re: [xri] Clarity around Ref processing behavior.

Steven Churchill wrote:
> Les has repeatedly called for other people's view on this issue,  
> and Andy
> has prepared an excellent article that I have attached. (Andy is not
> registered to send to the mailing list.)

I find Andy's argument compelling from a philosophical point of view.

But what worries me is that in his example, a proxy resolver would  
have to make calls to at least 8 different network endpoints to  
ascertain that a SEP was not available, or find all the SEPs of a  
particular type:
1. resolve andy at =
2. resolve ooTao at @
3. resolve andy at @ooTao
4. resolve mfkd at =
5. resolve yahoo at @
6. resolve mfkd at @yahoo
7. resolve wow at @
8. resolve mfkd at @wow

Given indeterminate network latency, the proxy resolver could be  
spinning its wheels for an unacceptable length of time.

Pardon me if I'm just not getting it, but wouldn't Refs at the  
Service level provide the same capabilities that Andy's use case  
requires, but in a more efficient way? So that if =andy wants to  
assert a freetime svc, it would include a Service element with that  
type, but no URI, only a Ref to @ooTao*andy.

It does make provisioning more complex, because the service would  
have to be provisioned both at @ooTao*andy and at =andy.
But provisioning doesn't need to happen in real time, resolution  
does. Besides, that could be a feature, providing even more  
flexibility about what can be discovered from where.

=vg