[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
Sam Johnston
samj at samj.net
Sun Oct 18 19:34:02 CDT 2009
Gary,
As you well know I'm all about transparency so if you're going to talk about
things that should be on the list then expect them to end up there
(deidentified if need be, as was the case this time at least until you
claimed ownership). I don't mind if people contacting us privately to
conceal their identity for whatever reason (there are a number of vendors
doing this and/or working through intermediaries) but private threads about
fundamental design decisions are not on.
Working through your mail:
- what RESTful principles are we diverting from exactly?
- what "portions" of REST should be applied? pursuing a goal of being
RESTful only to deliberately reject certain tenets doesn't really make sense
- you are or you're not.
- data *is* cacheable, just not by untrusted intermediaries as it's
encrypted with SSL. what would you have us do - disable encryption for
cacheability? how do you figure this is this "in opposition to some of those
principles"?
- we do need to represent actions and are doing a pretty good job of
avoiding creating an RPC-style interface. how do you figure this is this "in
opposition to some of those principles"?
- how do you figure HTTP verbs which effectively perform a series of
RESTful actions are not themselves RESTful?
- the "definition of REST as it applies to OCCI" is here:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
- your opinion on ReST for management applications is exactly that - an
opinion... it's lacking any justification so if you have a better
alternative then present it and explain clearly why it's technically
superior so as we can assess it on its merits
- I said this was not a forum for religious debates about $methodology,
nothing more
Finally, being as close as possible to HTTP as the "universal interface"
means we're already compatible with most systems and, more importantly,
developers feel at home with OCCI without needing to retool. I've
(fortunately) not heard anyone seriously suggesting that we should target
binary RPCs, SOAP, CORBA or SNMPv2 thus far and I would say that to do so
would be a fairly significant deviation from what we're trying to achieve.
Sam
On Sun, Oct 18, 2009 at 3:14 PM, Gary Mazz <garymazzaferro at gmail.com> wrote:
> Sam,
>
> I'm not "attacking" the api, I'm pointing out OCCI seems to be a diverting
> from the majority of ReSTful principals as many understand them.
>
> Note my first line: "As we move closer to practical working set of
> management actions, it appears we are moving further away from ReSTful
> principals."
>
> This needs examination and OCCI should clarify what portions of ReST will
> be applied and where. I'm finding under current writings about ReST, by
> creating new actions, and making data uncachable (by design or otherwise) is
> in opposition to some of those principals. I agree that OCCI optimizations
> are non-ReSTful, the reason for the email. I don't agree these are all
> performance optimizations, most are functions that make using OCCI practical
> and the API more intuitive.
>
> I think we need better definition of ReST as it applies to OCCI. And if the
> resource addressing scheme is the only applicable portion, we should qualify
> that.
>
> As for my opinion on ReST for management applications, I think it is "snake
> oil' and most don't understand the impacts to management applications. I've
> been looking for an analysis of protocol strategies pertaining to ReST and
> small data payloads, can't seem to find one. ReST does have its place in
> the world, but for practical management applications that need to operate
> securely on the public internet, IHO, most of ReST is just not a good fit as
> defined. After ten years, it may be time to revisit ReST, we may need a
> ReSTMgt for OCCI like applications.
>
> This is not addressing anything in "religious' context. My comments were
> not directed at any specific contributors, just the type of comments
> pertaining to ReST. Its a social phenomenon where questions and challenges
> to ReST's applicability illicits irrationally emotional responses about the
> subject. Its not even a technology, its a set of goals with a "recommended"
> nondescript addressing scheme. Second.... I didn't post my comments on ReST
> to this forum, you did. Don't think its a little odd you post my "private"
> email to a public forum and then say it not the proper place for this
> discussion ?
>
> As for technical merits, I'll be hitting those on multiple levels later
> this week. :-)
> I'm glad you brought up point of RPCs, I'm not an advocate of RPCs or state
> transfer methods. As long as they meet the goals and requirements of the
> project and are implementable. SO what's wrong with binary RCPs or SOAP or
> any other method like CORBA ? Your comments seem to indicate you have a
> strong opinion against using these technologies. The reason why there was
> strong advocacy, on my part, to support multiple interface implementations
> was to increase the usefulness of OCCI to cloud communities and create
> opportunities for OCCI adoption. IMO, it would be a good thing of someone
> adapted OCCI to a non-ReST interface like WEBM. That would provide direct
> integration to tools like nagios, tivoli, Openview and MS management console
> maybe increasing OCCI's value to the communities. I'd like to see an SNMPV2
> version of the interface for the holdouts. Supporting multiple non-ReST
> interfaces is an advantage to OCCI, not a drawback!!.
> cheers,
> gary
>
>
> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091019/11bd3a99/attachment.html
More information about the occi-wg
mailing list