[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
Gary Mazz
garymazzaferro at gmail.com
Sun Oct 18 08:14:21 CDT 2009
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
>
More information about the occi-wg
mailing list