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

Sun Oct 18 06:17:24 CDT 2009

[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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091018/1708383d/attachment.html 