[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt

Sam Johnston samj at samj.net
Mon Oct 19 00:53:08 CDT 2009 

On Mon, Oct 19, 2009 at 4:28 AM, Michael Behrens
<michael.behrens at r2ad.com>wrote:

>  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).
>

The initial idea to include WebDAV was from the ability to "mount" a cloud
and interact with it via the filesystem/explorer/finder. For example, to
deploy/migrate a virtual machine to/between cloud(s) one could just drag and
drop.

There's lots of cruft though (e.g. XML) so it's not in core, just a few of
the (obvious) verbs like COPY and MOVE that we would have otherwise had to
have defined ourselves.

Sam

Sam Johnston wrote:
>
> Michael,
>
> 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?):
>>     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>> 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>>
>>>>        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>>
>>>>
>>>>
>>>>
>>>>
>>>>            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>
>>>>        http://www.ogf.org/mailman/listinfo/occi-wg
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> occi-wg mailing listocci-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/20091019/9ff07e1b/attachment.html

More information about the occi-wg mailing list