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

Sun Oct 18 18:58:25 CDT 2009

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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091019/86e23760/attachment.html 