> 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. KrisReceived on Monday, 1 September 2008 14:26:30 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC