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

[Sam Johnston]

Adding James Snell @ IBM to the thread as this is straying very close to
draft-snell-http-batch
<http://tools.ietf.org/html/draft-snell-http-batch>and may well be
another use case for same.

Also subbing reststar-board for Bill's direct email as it's the wrong forum
for technical discussions.

Sam

On Fri, Oct 16, 2009 at 3:35 PM, Sam Johnston <samj at samj.net> wrote:

> 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/6342c408/attachment.html