[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
Michael Behrens
michael.behrens at r2ad.com
Sun Oct 18 21:28:05 CDT 2009
Sam - Yes, saw them in the spec. I just was looking up the PATCH verb,
which could be useful - as it helps the server know exactly what to
change. Some other verbs from WebDAV which might be useful in the
future too (the check in/out and versioning ones).
Sam Johnston wrote:
> Michael,
>
> On Sun, Oct 18, 2009 at 10:35 PM, Michael Behrens
> <michael.behrens at r2ad.com <mailto: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?):
> http://annevankesteren.nl/2007/10/http-methods
>
>
> 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
>
> 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 <mailto: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)
>
>
>
--
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/902e49e5/attachment.html
More information about the occi-wg
mailing list