[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [rest-practices] Atom as a generic container? [was Re: Media types]

Eoghan Glynn wrote:

 > On one hand maybe somebody wants to listen for updates to VMS.
> 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.

Hi Bill,

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.

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.

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?

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.

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.

Bill Burke
JBoss, a division of Red Hat

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]