[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
Michael Behrens
michael.behrens at r2ad.com
Sun Oct 18 15:35:56 CDT 2009
FYI: In looking around for a list of HTTP verbs with specification
mappings....I found this one (is there a better one?):
http://annevankesteren.nl/2007/10/http-methods
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) representation
> - 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 participate)
> - 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
> OCCI.
>
> 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
>
> -<AC>
>
> 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).
>
> Sam
>
> On Fri, Oct 16, 2009 at 4:09 AM, Sam Johnston
> <samj at samj.net <mailto:samj at samj.net>
> <mailto: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.
>
> Sam
>
> ---------- Forwarded message ----------
> From: *Mark Nottingham* <mnot at mnot.net
> <mailto:mnot at mnot.net> <mailto:mnot at mnot.net
> <mailto:mnot at mnot.net>>>
> Date: Fri, Oct 16, 2009 at 1:48 AM
> Subject: Fwd: New Version Notification -
> draft-dusseault-http-patch-15.txt
> To: HTTP Working Group <ietf-http-wg at w3.org
> <mailto:ietf-http-wg at w3.org>
> <mailto:ietf-http-wg at w3.org <mailto:ietf-http-wg at w3.org>>>
>
>
>
>
> New version (-15) has been submitted for
> draft-dusseault-http-patch-15.txt.
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt
> Sub state has been changed to AD Follow up from New
> Id Needed
>
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-15
>
> IETF Secretariat.
>
>
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org <mailto:occi-wg at ogf.org>
> <mailto:occi-wg at ogf.org <mailto:occi-wg at ogf.org>>
>
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
>
>
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
--
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell)
(703) 714-0442 (land)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091018/21657e61/attachment.html
More information about the occi-wg
mailing list