[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]