> That's an even better reason why this isn't a good idea. You'd never be able to > effectively insert a cache if you had special semantics tied to if-modified-since. OK, thanks Bob & Bill for the clarification, it now fairly clear that the delta encoding route is not the way to go. > Are you interested in always getting the latest view of the VM collection? > Or are you interested in each change event that happened to the collection? Yes and yes ;) The idea was to get an initial collection of VMs satisfying certain criteria, but then to also retrieve updates as the status of the VM collection changes, without necessarily re-evaluating the entire query. So I'm thinking now of a simpler alternative approach that uses neither If-Modified-Since nor Atom (as the conduit to push out updates). I'll flesh these ideas out on Monday and do some prototyping. Cheers, Eoghan <div class="gmail_quote">On 17 April 2010 16:01, Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im"> Eoghan Glynn wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Yeah, I take your point Bill, I may have been over-gilding the lily ... > I think what you are suggesting (if I'm understanding right) of using If-Modified-Since > semantics as a query-like mechanism is overloading the *actual* meaning of this header. > This header is meant for conditional reads or updates to save bandwidth (read) Yes, there would be a subtle change to the semantics of If-Modified-Since, in the sense of escaping the "all or nothing" straight-jacket. So the idea is to avoid a conditional GET being returned either /nothing/ (304 "Not Modified") if not a single entry in the feed has changed, or /everything/ (the entire Feed) even if only a relatively small subset of the entries have been updated. You're absolutely correct that this does go against the letter of the spec, which requires that a non-empty return would be exactly the same as for a normal GET. Though I'd argue that the delta semantics are still kinda within the "spirit of the spec" ;) > In the REST-* messaging work I did, a "next" link header is provided with each event > posted to the feed (or topic as is referenced in the spec). This "next" link points to the > next *sequenced* event and acts as an index pointing to a specific place in time. This is interesting, maybe we can structure the provision of updates to the VM collection in a similar way. There was a suggestion previously of taking a paginated approach, but I didn't really like the idea that the state of VMs reported in earlier "pages" could have changed by the time the later "pages" are retrieved. But perhaps explicitly treating the "next" link as a pointer to /future/ updates would avoid that sort of messiness. </blockquote> </div> I'm not sure what the end goal is here. Are you interested in always getting the latest view of the VM collection? Or are you interested in each change event that happened to the collection? If its the former, then a conditional GET using if-modified-since or if-not-match is the best approach even if there are query parameters (I'm pretty sure caches are ok with query parameters). If its the latter, a link approach is better IMO.<div> <div></div><div class="h5"> -- Bill Burke JBoss, a division of Red Hat <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a> </div></div></blockquote></div>