[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
samj at samj.net
Sun Oct 18 18:58:25 CDT 2009
On Sun, Oct 18, 2009 at 10:35 PM, Michael Behrens
<michael.behrens at r2ad.com>wrote:
> FYI: In looking around for a list of HTTP verbs with specification
> mappings....I found this one (is there a better one?):
Anne's is the most useful one I've seen but you did see that I've referred
back to a normative reference (usually an RFC) for each of the verbs
included in the OCCI spec, right?
> Sam Johnston wrote:
> [moving this off-list discussion to the list where it belongs]
> On Sun, Oct 18, 2009 at 12:40 PM, <AC> wrote:
> As we move closer to practical working set of management actions, it
>> appears we are moving further away from ReSTful principals. Now, we have 4
>> additional actions HEAD, OPTIONS, MOVE, and PATCH over the ReST CRUD. We
>> haven't even begun to here from user wanting CHECKPOINT, COPY and CLONE (a
>> live checkpoint copy).
> All of these verbs are useful and none of them are particularly non-RESTful
> - in fact they're effectively performance optimisations:
> - HEAD allows one to retrieve metadata without the entire (possibly large)
> - OPTIONS allows you to "look before you leap"
> - COPY allows a remote client to request a resource be transferred (short
> for GET followed by PUT, only allows e.g. EDGE connected iPhones to
> - MOVE is like COPY, only it's short for GET-PUT-DELETE (again avoiding
> the need to transfer the whole lot via the client)
> - PATCH is like PUT, only it doesn't require the entire entity to be
> transferred (rather just the changes in e.g. diff format)
> Without these optimised HTTP verbs it would be literally impossible to, for
> example, migrate a virtual machine from one cloud to another from a client
> sitting on a "slow" connection like 3G/EDGE/GPRS, or even ADSL. Note also
> that they have all been standardised at some point by the IETF, either in
> HTTP itself or WebDAV.
> Nobody's talking about introducing our own non-standard HTTP verbs for
> Using SSL and other secure protocols, we eliminate any possibility to
>> leverage existing document cache infrastructures.
> No, we eliminate the possibility for *untrusted intermediaries* to cache,
> which is by design.
> As OCCI continues to mature towards practical design, many aspects of
>> ReST seems to be incompatible with real world management applications.
>> Outside of the resource addressing scheme, which is very similar to SNMP
>> and CMIP/CMOT in concept, ReST provides very little to guide the direction
>> of our technical decisions. In fact, the more I think of it, the more it
>> looks like "snake oil". It appears to have a large following of "devotees",
>> drinking that koolaid and blindly chant a ReST mantra. The scary part is,
>> most don't have a clue of impacts or its proper application.
> Attacking an API for being RESTful after it's been written (based on a
> clear consensus to be RESTful no less) is not what I would call
> "constructive criticism", especially when framed as a religious debate when
> it's not. There are plenty of forums for such "discussion" but this isn't
> one of them - we're assessing all the options on technical merit with a view
> to reaching a rough consensus and producing running code (even if we're not
> the ones writing it).
> If you insist on having this discussion then I would suggest focusing on
> the content rather than the contributors, for example by highlighting
> specific instances where REST fails to deliver *and* where RPC would have
> done a better job. Good luck with that.
>> Sam Johnston wrote:
>>> On Fri, Oct 16, 2009 at 7:32 PM, <AC> wrote:
>>> And, how does this impact the implementation of ReSTful principals
>>> as called out in the last draft of the occi specification ?
>>> It doesn't. It just provides a shortcut for someone who wants to make a
>>> minor change (e.g. the number of compute cores) to a large representation
>>> (e.g. OVF for an entire cluster).
>>> On Fri, Oct 16, 2009 at 4:09 AM, Sam Johnston <samj at samj.net
>>> <mailto:samj at samj.net>> wrote:
>>> Afternoon all,
>>> The HTTP PATCH verb is interesting in that it allows you to
>>> update a representation without having to transfer the entire
>>> thing. It's a space-time tradeoff in that it's a smaller
>>> transfer but you then have to generate and apply the patch,
>>> but for large/complex representations and remote (e.g. iPhone)
>>> users it could provide significant benefit. I wouldn't suggest
>>> that it be required at this time given lack of implementation
>>> (e.g. Apache) support but I've added a reference to it to OCCI
>>> as it will be useful for some applications and I'd rather
>>> provide the functionality than have people invent it.
>>> It's worth noting that PATCH first made an appearance (along
>>> with LINK and UNLINK) in the first HTTP RFCs but wasn't
>>> included in more recent releases due to lack of implementations.
>>> ---------- Forwarded message ----------
>>> From: *Mark Nottingham* <mnot at mnot.net <mailto:mnot at mnot.net>>
>>> Date: Fri, Oct 16, 2009 at 1:48 AM
>>> Subject: Fwd: New Version Notification -
>>> To: HTTP Working Group <ietf-http-wg at w3.org
>>> <mailto:ietf-http-wg at w3.org>>
>>> New version (-15) has been submitted for
>>> Sub state has been changed to AD Follow up from New Id Needed
>>> Diff from previous version:
>>> IETF Secretariat.
>>> Mark Nottingham http://www.mnot.net/
>>> occi-wg mailing list
>>> occi-wg at ogf.org <mailto:occi-wg at ogf.org>
> occi-wg mailing listocci-wg at ogf.org
> Michael Behrens
> R2AD, LLC
> (571) 594-3008 (cell)
> (703) 714-0442 (land)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the occi-wg