Re: issue 85 - range unit extensions

> Yes, a registry or a convention for range-unit namespaces, like
> "com.dojo.items", or even "items{uuid=UUID}".
>
> Or simply declare that "items" is application-specific.  Only use it
> with known resources, and caches should not do anything clever with
> it.

It certainly is not intended to be application specific, it is intended to 
be very general purpose, I wouldn't want it tied to Dojo, if possible.

> Yves Lafon wrote:
>> >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.
>
> Range "items" doesn't explain what the meaning is either.  It just
> gives a really vague idea.  What kind of items?

At least in the context of JSON, items can be reasonably clear. I would 
think other structured data formats may also have entity that could be 
well-defined.
>
> "Dojo-Range: 6 items" seems clearer.

This is kind of the antithesis of what we were aiming for. We wanted 
something interoperable with other technologies, not Dojo-specific.

> Are caches allowed (in principle) to split/merge these ranges, if they
> knew how?  Would such caches operate on the item syntax -
> i.e. structured JSON in the message body?

Yes and yes, I thought that was the idea of Ranges.

Kris