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.

Thanks,
Kris 

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