proposal for capabilities lookup

[Ernst Johannes]

Anybody have an opinion on this subject?


On Nov 17, 2005, at 15:35, Dan Libby wrote:

> On Thursday 17 November 2005 17:14, Ernst Johannes wrote:
>> On Nov 17, 2005, at 14:41, Dan Libby wrote:
>>
>>> 9.2 OPTIONS
>>>
>>>    The OPTIONS method represents a request for information about the
>>>    communication options available on the request/response chain
>>>    identified by the Request-URI. This method allows the client to
>>>    determine the options and/or requirements associated with a
>>> resource,
>>>    or the capabilities of a server, without implying a resource  
>>> action
>>>    or initiating a resource retrieval.
>>
>> That doesn't alleviate your concern about too many round-trips,
>> however, does it? Maybe I misunderstand what you are saying.
>
> Well, if we make a single OPTIONS request, and that request returns  
> a YADIS
> capabilities document, then:
>  a) we have one request/response instead of 2
>  b) we do not have to parse any nasty and possibly huge and  
> bandwidth wasting
> html.
>
>>
>>>    Responses to this method are not cacheable.
>>
>> We don't mean this one, do we? I consider capability documents to be
>> eminently cacheable -- probably more so than regular content  
>> documents.
>
> I think we could safely ignore that at the consumer.  It is a  
> concern for
> proxy-caches. Or there may be another solution, such as specifying  
> a max
> cache lifetime within the capabilities doc, and making that part of  
> YADIS,
> rather than HTTP.
>
>>
>> This last part does not seem to apply.
>>
>> This command seems to be more of a "tell me how smart the server is"
>> kind of thing than a "tell me what this resource, hosted by some
>> server, can do".
>
> I don't interpret it that way.  Specifically:
>
>  If the Request-URI is not an asterisk, the OPTIONS request applies
>  only to the options that are available when communicating with that
>  resource.
>
> Thus, the returned document should specify capabilities for the  
> requested
> resource ( URL ).
>
> The biggest issue seems to be that the spec is silent about the  
> format of the
> returned document.  But I think that is fine so long as the  
> consumer sends an
> Accept header that requests a yadis doc.
>
>
> Anyway, I raise it as a possibility.
>
> -- 
> Dan Libby
>
> http://videntity.org/
>  - One identity to login with them all
>  - Social networking between websites and blogs

Johannes Ernst
-------------- 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/20051117/06ce709f/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst