Sam Johnston wrote:
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? I went back to Fielding's original document . Here in chapter 5
/5.2.1.2 Representations/ /REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components. *" A representation is a sequence of bytes, plus representation metadata to describe those bytes." * Other commonly used but less precise names for a representation include: document, file, and HTTP message entity, instance, or variant./ /A representation consists of data, metadata describing the data, and, on occasion, metadata to describe the metadata (usually for the purpose of verifying message integrity). Metadata is in the form of name-value pairs, where the name corresponds to a standard that defines the value's structure and semantics. Response messages may include both representation metadata and resource metadata: information about the resource that is not specific to the supplied representation./ In this chapter Fielding specifically calls out that all ReST represented data must has a key value pair and must be in an document, file, HTTP message entity , instance, or variant. I can completely understand this position, it places data in a position available to web cache logic. Moving the OCCI key value pairs into HTTP headers does not align with the Fielding requirement.
- 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. I'm not saying deliberately reject any of it, I challenge its applicability to the use models. For example, "code-on-demand " is a ReST feature, albeit optional, we are not implementing that feature today. Maybe there will be a requirement for it in the future, but today we are deliberately not supporting it. Does it really make sense to include it ? Which of the "certain tenets"
- 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 to comply with Fielding paper on cache see below
/5.1.4 Cache In order to improve network efficiency, we add cache constraints to form the client-cache-stateless-server style of Section 3.4.4 (Figure 5-4). Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests. / We currently do not specify any cache constraints for OCCI response data. Since most providers are using the public internet, secure OCCI APIs are required. Public web caches will not cache SSL or vpn HTTP response data. This needs to be implemented, addressed and disclosed in either the specification or though adjunct documentation. Not complying with 5.1.4 is in conflict with ReST criteria.
- 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"? I believe that statement to be true, until recently. - how do you figure HTTP verbs which effectively perform a series of RESTful actions are not themselves RESTful? The only verbs I've found commonly agreed to represent ReST are CRUD operations. Additional actions, without the support of the "ReST" community via consensus should not be considered ReST complaint. It would be similar to a third party cloud working group adopting OCCI, adding new verbs and calling these new verbs OCCI compliant. Those new verbs would only be compliant after the OCCI-wg approves them. The same is true for ReST. That also is the reason for my suggestion to reexamine ReST and maybe call for a ReSTMgt supporting new verbs for OCCI and other management actions. - the "definition of REST as it applies to OCCI" is here: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm <http://www.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm> This is the doc I'm looking at... - 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
My justifications are above.
- 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. No one is calling for a retool, like the one that occurred a week before OGF 27. Now, that you pressed the issue, I'll be calling for a reexam and review for parity to mission and goals with better definition of ReST requirements with respect to the project and close out all these loose ends.. Asking for a review, better requirements and statement of execution, for ReST, is not asking to rewrite the interface...
AS for HTTP being a "universal interface", that is not true for all industries. -gary
Sam
On Sun, Oct 18, 2009 at 3:14 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@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@samj.net <mailto:samj@samj.net> <mailto:samj@samj.net <mailto:samj@samj.net>> <mailto:samj@samj.net <mailto:samj@samj.net> <mailto:samj@samj.net <mailto:samj@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@mnot.net <mailto:mnot@mnot.net> <mailto:mnot@mnot.net <mailto:mnot@mnot.net>> <mailto:mnot@mnot.net <mailto:mnot@mnot.net> <mailto:mnot@mnot.net <mailto:mnot@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@w3.org <mailto:ietf-http-wg@w3.org> <mailto:ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>> <mailto:ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org> <mailto:ietf-http-wg@w3.org <mailto:ietf-http-wg@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@ogf.org <mailto:occi-wg@ogf.org> <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>> <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org> <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>>>
http://www.ogf.org/mailman/listinfo/occi-wg
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg