<br>> If a content handler was written for this delta type you're talking
about, <br>> then I could probably easily modify the lightweight Atom classes
in <br>> RESTEasy to extract the object you're interested in.<br><br><br>Hi Bill,<br><br>I don't think any new type support is needed for the RFC3229+feed idea, rather it would be more a case of just filtering out older entries from the feed, and then marshalling the pruned feed in exactly the same format as before (just with a different status code, 226 "IM Used", and also an extra header IIRC).<br>
<br>I guess this filtering could be done manually, but we probably wouldn't want to be creating separate new Feed objects for each different If-Modified-Since timestamp that we see.<br><br>Cheers,<br>Eoghan<br><br><br>
<div class="gmail_quote">On 16 April 2010 21:38, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>></span> wrote:<br><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"><br>
<br>
Eoghan Glynn wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
 > On one hand maybe somebody wants to listen for updates to VMS.<br>
 ><br>
 > On the other hand, I don't see the point of using Atom for returning collections.  It was written as a format for feeds not a collection format.<br>
<br>
<br>
Hi Bill,<br>
<br>
So just to clarify, the original idea wasn't so much to wrap the VMs collection in an Atom feed, but rather to use a feed to allow clients, having previously executed a query over the VM collection, to receive lightweight notifications of changes to the set of known VMs and their status. For example a new VM appears, the status of another VM changes, a third VM goes away, etc.<br>

<br>
This would allow clients to update their previous result set, without necessarily re-issueing the original query. It would of course depend on the feed being filtered on the client-side according the original query constraints.<br>

<br>
To ensure that only genuinely fresh updates were received, idea was to use delta encoding with the cleint setting the "A-IM: feed" header so that it recieves only those entries that were updated later than the If-Modified-Since header (set to the timestamp of the original query or the last GET on the Atom feed, which-ever is the later). It was an open question whether the RESTeasy Atom provider supported delta encoding in this way. I'll need to check this out, unless you know off the top of your head?<br>

<br>
</blockquote>
<br></div>
Resteasy's atom support is just a bunch of JAXB classes.  The Content class has a bit more logic in that it allows you to extract application-specific JAXB content.  That's it.<br>
<br>
If a content handler was written for this delta type you're talking about, then I could probably easily modify the lightweight Atom classes in RESTEasy to extract the object you're interested in.<div><div></div><div class="h5">
<br>
<br>
-- <br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
</div></div></blockquote></div><br>