[occi-wg] Modeling proposal for ReST/Cloud based commands.

[Sam Johnston]

On Thu, Oct 15, 2009 at 2:35 AM, Bill Burke <bburke at redhat.com> wrote:

>
> As for pubsubhubbub, I don't like the reliance on Etag semantics for
> polling.  Feels like you're tunneling a protocol.  I'd much prefer to send a
> link back to the client telling it how it can get further (new) data.  I
> also don't like the reliance on Atom.  Atom is fine for text formats, not
> great for others.  So, what I'm going to do is turn Atom's (and messaging
> metadata in general, Atom's metadata isn't something revolutionary) Into a
> set of headers and use multipart to send batches.  IMO, multipart is much
> more appropriate.
>

Just quickly on this point on PuSH, apparently Atom's intended as a
bootstrap format, though you and I both know how these things go - once it's
burnt into code it's there forever. I'd suggest sharing your concerns with
the pubsubhubbub group <http://groups.google.com/group/pubsubhubbub> who are
generally fairly responsive (copying Brett - one of the PuSH "instigators").

I'd like to explore the topic of batches (what we call "collections") a bit
more as currently I've sidestepped the issue somewhat by specifying
text/uri-list be used to pass a list of resources by reference (sans
metadata) rather than by value (e.g. embedded in Atom). This requires O(n+1)
requests which isn't great for performance but it works it's easily
optimised later.

The question then is how to do it. Ideally HTTP would allow us to request a
single resource and have it return multiple responses (that is, full blown
HTTP responses, headers and all). Technically this would be fairly
straightforward, for example by avoiding parsing for boundaries by using
content-length as a delineator for the end of this message (and therefore
the start of the next) - but it would require a version bump for HTTP. The
IETF boffins claim that collections are done in WebDAV but that's all based
on XML and is like taking a sledgehammer to a tack. One can use envelope
formats like SOAP or Atom but that's also fairly heavy handed. In any case
this is unlikely to happen in our timeframes.

Using MIME isn't a bad idea per se, but it does mean your client not only
needs to understand multipart/mixed MIME (and scan for boundaries) but then
also needs to be able to decipher each of the message/http contained
therein. Many clients include support for the former but not the latter.
That said the format is trivial, especially given the alternatives, so this
may still be both the path of least resistance and the option that is
"closest" to HTTP.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091016/a434ea13/attachment.html