Re: issue 85 - range unit extensions

> There may be other media types that follow those same rules, but off the
> cuff it seems pretty media-type-specific (unless we abandon the hope
> that caches could do that recombination). It's certainly *not*
> vendor-specific--there's no need to call them 'Dojo-items' or
> 'com.dojo.items'. One possibility would be to leave the range
> declaration media-type-neutral ('items') and to add range-recombination
> rules to the media-type itself, so that RFC 4627 (application/json)
> would eventually grow a paragraph on its rules for items-ranges.

Yes, that is what I would hope for.

>> > (Btw, one can easily imagine ranges "characters", "xpath", "xquery",
>> > "grep"... even "session".  I'm not sure if that's a desirable road
> to
>> > go down.  Maybe it would be very useful.)
>> "date" ranges is the one other unit that I have felt would be useful,
> Which dates did you have in mind?

Well, it had occurred to me that it might be useful for a client to be able 
to retrieve a set of all new (or modified) resources from a collection by:

GET /MyCollection/ HTTP/1.1
Range: date=Mon, 01 Sep 2008 19:33:44 GMT-

This would retrieve all the entities in the collection since the provided 
date. For a frequently updated collection, it would seem more efficient to 
be able to get a list of only the items/resources that are new or updated 
since the last time it was retrieved, rather than using an If-Modified-Since 
and downloading the whole collection if something has changed.

Anyway, I didn't intend to distract, I haven't put all that much thought 
into this approach, it may be too high level for HTTP or simply wrong. 
Indexed based ranges is certainly my main desire.


Received on Monday, 1 September 2008 19:44:09 UTC