- From: Kris Zyp <kris@sitepen.com>
- Date: Mon, 1 Sep 2008 13:41:29 -0600
- To: "Robert Brewer" <fumanchu@aminus.org>, "Jamie Lokier" <jamie@shareable.org>
- Cc: "Yves Lafon" <ylafon@w3.org>, "Julian Reschke" <julian.reschke@gmx.de>, <ietf-http-wg@w3.org>
> 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