OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]