- From: Yves Lafon <ylafon@w3.org>
- Date: Mon, 1 Sep 2008 08:23:05 -0400 (EDT)
- To: Jamie Lokier <jamie@shareable.org>
- cc: Julian Reschke <julian.reschke@gmx.de>, Kris Zyp <kris@sitepen.com>, ietf-http-wg@w3.org
On Mon, 1 Sep 2008, Jamie Lokier wrote:
> Julian Reschke wrote:
>>> interoperability with servers by following the HTTP specification as
>>> closely as possible, so servers have a real standard to go off of
>>> instead something we made up. It seems like leveraging the range/partial
>>> content mechanism with alternate range unit is the approach that HTTP
>>> would suggest, and I have no reason to believe it is wrong. Retrieving a
>>> paged subset of data is merely a different representation of the same
>>> resource.
>>
>> Yes. But, making up new range units shares has similar problems as
>> making up query parameters, doesn't it?
>>
>> To make this robust, we'd really need a registry.
>
> Yes, a registry or a convention for range-unit namespaces, like
> "com.dojo.items", or even "items{uuid=UUID}".
It should contain "universal" units (bytes, seconds, characters), as well
as custom one, how about an URI to identify the unit, as well?
> Or simply declare that "items" is application-specific. Only use it
> with known resources, and caches should not do anything clever with
> it.
>
> Or use a different header: Dojo-Range, with the response containing
> "Vary: Dojo-Range". That would make it cachable by generic HTTP
> caches, which sounds rather desirable.
The "different header" will not explain what the meaning of the range is,
unless it is a standardized header meant to describe in general
range units.
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Monday, 1 September 2008 12:23:39 UTC