May 2009 - occi-wg - lists.ogf.org

moving forward
by Alexis Richardson 01 Jun '09

01 Jun '09

Hi all, I spoke with Thijs today who has been representing OCCI at the current OGF meeting. The feedback from OGF leadership is that they are pleased with our progress and the level of participation. But they would also like us to move on from the deep discussions about formats, a view with which I think *everyone* on the list agrees. A lot has been said about different approaches and we now risk repetition, deviation and hesitation; which I for one do not want to see persist. Now is the time to stake out areas where consensus exists - to try to seek rallying points. Where are those to be found? I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last week and had a set of very interesting conversations. I was left with the feeling that the first task is to identify areas where there is agreement, and from there establish consensus, from which basis a course of action can be proposed. I'd also like to thank Sam for his thoughtful emails on HTTP from his own work after last week's meetings. These give me cause to believe we all want to converge. On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people: * People with cloud implementation experience who want to implement OCCI. We need more than one prototype implementation for this process to be useful. It will NOT help us to create an OCCI that nobody wants to implement. Let's bring the implementers into the fold more, both open source software people and service providers. * End users who represent real world cases especially from, e.g. enterprises. We don't want to build a castle in the sky and we must look to our requirements to bring us down to earth. Requirements are necessary to move us forward from prior art to the standard. Let's bring more real world requirements to OCCI and make this thing really concrete. So: We all need to reach out to people that we know who can join the conversation. If we have enough of them, we can get enough meaningful participation from implementers and requirements advocates, to hammer out something really plausible. PLEASE can everyone do that - reach out to people. I personally think we have something to show people: we have done good work on the state model, as a group, and Andy et al., have worked on formalising and tidying it up. This is great - but not enough to achieve consensus on the next steps. So, what have we not done yet? We have not focussed on the semantics of RESTful interactions with the cloud - the actual API and interop definitions. I have not seen clear statement of requirements here, rather I fear we have let ourselves get sidetracked by too much talk about HOW the OCCI operations might be expressed, which may impact integration, and not enough about WHAT they do (which is critical for defining behavioural semantics). By the same token (no pun intended), by concerning ourselves with one metamodel style over another, we risk coming to the actual interoperable behavioural protocol as an afterthought. Let's not do that. Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?" I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here? A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop. C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people. D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings. What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work? alexis

12 32

Fwd: Versioning?
by Sam Johnston 31 May '09

31 May '09

Oops... including list. ---------- Forwarded message ---------- From: Sam Johnston <samj(a)samj.net> Date: Sun, 31 May 2009 19:20:50 +0100 Subject: Re: [occi-wg] Versioning? To: Mark Masterson <mmasterson(a)csc.com> Mark, Are you implying we might not get it right the first time? ;) I thought I'd mentioned this point before but apparently not... I too had read those references and thus far was planning to leave version cruft out of the purl.org URLs, content types, etc. knowing that it can be easily added later should there be revisions. That said our extension mechanisms should cater for most change (eg new verbs, attributes and perhaps even nouns) without having to break existing systems. Also refer to my earlier rants about the core protocol providing only extensibility. HTTP will likely always be 1.1 but that's not to say the spec is immutable - just look at the Link: headers which will allow us to avoid Atom for individual resources. Sam on iPhone On 5/31/09, Mark Masterson <mmasterson(a)csc.com> wrote: > What about versioning the API? This is surprisingly hard to get right, but > (for many, just as surprisingly) awfully important -- I have seen numerous > enterprisey distributed system efforts fail for just (and entirely) this > reason. There is no mention in any of the three APIs being talked about > here (GoGrid, EH, or Sun) of versioning that I can find? Nor do I recal it > being discussed as a first class design goal on this list yet? On the wiki > there is no mention of it in the API Design section. > > Although I confess that I have never used it in anger, there is a > fascinating proposal for attacking versioning in a RESTful way here: > http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ (with > some caveats here: > http://barelyenough.org/blog/2008/05/versioning-rest-web-services-tricks-an… > ). The REST gurus in this group may well know an even better way to solve > the problem. > > I'd be interested in hearing others' views on this. > > > Mark Masterson > Enterprise architect, troublemaker > CSC > > Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss > Masterson | Public blog: Process Perfection > (http://jroller.com/MasterMark/) | mmasterson(a)csc.com | www.csc.com. > > > CSC • This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the mistake > in delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the use of e-mail > for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal > Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered > in England No: 0963578 > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg >

1 0

Fwd: Structured data over TCP?
by Sam Johnston 30 May '09

30 May '09

Tim's presentation is insightful. Highlights (actually it's all good so this is most of the presentation): - Use plain text if... you possibly can. - JSON issues: Watch out for extensibility. - Use JSON if... The expected lifetime of the data is short. - Use XML if... your data is document flavoured or you're worried about i18n, extensibility or reusability. - Inventing New XML Languages: - Time-consuming. - Bureaucratic. - Difficult. - Unpleasant. - Includes complex software development as a sub-task. - Usually fails. - ... so try not to! - Some Good XML Languages - XHTML - DocBook - ODF - Atom - XMPP - UBL - RDF - Design Issue: Model vs. Syntax - “What matters is getting the data model right. The syntax is ephemeral.” vs - “The bits on the wire are the only reality.” - Design Issue: Minimalism vs. Completeness - “Let’s solve the whole problem.” - “Minimum progress required to declare victory.” - XML Schema Definitions (XSD): - Hard to understand, hard to implement, hard to interoperate. - One of the reasons why the SOA/WS-* project is sinking. - XML Extensibility: Three Options - No changes. - Must-Understand policy (e.g. as in SOAP). - Must-Ignore policy (e.g. as in Atom). Morals of the story (IMO): - Bend over backwards to use plain text (if we can) - JSON is more interesting for RPC than ROA (Resource Oriented Architecture) - Avoid inventing new [XML] languages at all costs - 6 of the 7 "good" XML languages have already come up in the context of OCCI (NFI what UBL is) - Model and bits-on-the-wire are both important to us - RELAX NG and XPath is a GoodThing™ - For XML extensibility ignore that which you don't understand (ala Atom) - Solve as much of the problem as we need to now but provide for extensibility later Sam ---------- Forwarded message ---------- From: Tim Bray <tbray(a)textuality.com> Date: 2009/5/27 Subject: Re: Structured data over TCP? To: Patrik Fältström <patrik(a)frobbit.se> Cc: apps-discuss(a)ietf.org 2009/5/26 Patrik Fältström <patrik(a)frobbit.se>: > Do Apps Area have any general feeling about this? I was going to start typing in a lengthy answer but then I remembered I gave a tutorial at IETF70 on the choice of data formats for use in Internet Protocols. It's centered around XML but I think covers many of the other issues that have come up in this. Available for your reading pleasure at http://www.tbray.org/tmp/IETF70.pdf -Tim _______________________________________________ Apps-Discuss mailing list Apps-Discuss(a)ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss

2 2

(no subject)
by Andre Merzky 30 May '09

30 May '09

Could Amazon indeed open it's AWS APIs? Just rumours at the moment though... http://ostatic.com/blog/is-amazon-going-to-open-source-its-web-services-and… -- Nothing is ever easy.

2 1

OCCI in the Economist?
by Alexis Richardson 29 May '09

29 May '09

An oblique reference at the end? http://www.economist.com/opinion/displayStory.cfm?story_id=13740181&source=…

1 0

Revised the Sun API lightly
by Tim Bray 28 May '09

28 May '09

Not in a deep way; in response to people worried about administrative control policies. Here's how it works now: A Virtual Data Center contains a collection of VM templates, a collection of available public IP addresses, and a single Cluster resource. A Cluster resource contains, along with some actuator URIs, a collection of private networks, a collection of virtual machines, and zero or more child clusters. The idea is that the general-purpose Cluster grouping resource now acts just like a nested filesystem. Private networks belong to clusters, but only for administrative purposes; they can be attached to any VM in any cluster. (What's changed? Previously, clusters didn't nest and private- networks were allocated at the VDC level). The motivation is, we hear from people, especially private-cloud people, that they want to hand out authorization rights to control particular sets of VMs and private-networks, but not others. It wasn't obvious how you'd go about doing this. So now everything that you might reasonably want to control/administer has a primary association to a Cluster object, making that the obvious hook to attach administrative-rights policies. (If people don't want these FYI posts about parallel work in another API-building effort, say so and I'll shut up). -Tim

2 1

Agenda for tomorrows meeting @OGF (1:30pm EDT)
by Thijs Metsch 28 May '09

28 May '09

Hi guys, This is the current agenda for tomorrows meeting. There will be 5 presentations: 0. Introduction to OCCI - Thijs Metsch 1. Alexander Papaspyrou 2. Tino Vazquez (via skype) 3. Augusto Ciuffoletti (via skype) 4. Richard Davies (via skype) The first session takes place from 1:30pm till 3pm. The second session will be from 3:30pm till 5pm. The second session is for an open group discussion. All times are given for the EDT timezone. To match it up with your timezone visit: http://www.timeanddate.com/worldclock/meeting.html We'll use the same teleconference bridge as usual. Please see: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… To all presenters: if you haven't done already can you send me the slides? Or at least the conrete titles So I can update the ogf pages accordingly? That would be great! Thanks in advance! All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

4 9

All please read
by Alexis Richardson 28 May '09

28 May '09

Sam, Thank-you very much for posting this. I agree that Tim's PDF is insightful, and relevant to our situation. ALL - please read Tim's deck linked to at the bottom of Sam's post. alexis On Wed, May 27, 2009 at 8:49 PM, Sam Johnston <samj(a)samj.net> wrote: > Tim's presentation is insightful. > > Highlights (actually it's all good so this is most of the presentation): > > Use plain text if... you possibly can. > JSON issues: Watch out for extensibility. > Use JSON if... The expected lifetime of the data is short. > Use XML if... your data is document flavoured or you're worried about i18n, > extensibility or reusability. > Inventing New XML Languages: > > Time-consuming. > Bureaucratic. > Difficult. > Unpleasant. > Includes complex software development as a sub-task. > Usually fails. > ... so try not to! > > Some Good XML Languages > > XHTML > DocBook > ODF > Atom > XMPP > UBL > RDF > > Design Issue: Model vs. Syntax > > “What matters is getting the data model right. The syntax is ephemeral.” vs > “The bits on the wire are the only reality.” > > Design Issue: Minimalism vs. Completeness > > “Let’s solve the whole problem.” > “Minimum progress required to declare victory.” > > XML Schema Definitions (XSD): > > Hard to understand, hard to implement, hard to interoperate. > One of the reasons why the SOA/WS-* project is sinking. > > XML Extensibility: Three Options > > No changes. > Must-Understand policy (e.g. as in SOAP). > Must-Ignore policy (e.g. as in Atom). > > Morals of the story (IMO): > > Bend over backwards to use plain text (if we can) > JSON is more interesting for RPC than ROA (Resource Oriented Architecture) > Avoid inventing new [XML] languages at all costs > 6 of the 7 "good" XML languages have already come up in the context of OCCI > (NFI what UBL is) > Model and bits-on-the-wire are both important to us > RELAX NG and XPath is a GoodThing™ > For XML extensibility ignore that which you don't understand (ala Atom) > Solve as much of the problem as we need to now but provide for extensibility > later > > Sam > > ---------- Forwarded message ---------- > From: Tim Bray <tbray(a)textuality.com> > Date: 2009/5/27 > Subject: Re: Structured data over TCP? > To: Patrik Fältström <patrik(a)frobbit.se> > Cc: apps-discuss(a)ietf.org > > > 2009/5/26 Patrik Fältström <patrik(a)frobbit.se>: > >> Do Apps Area have any general feeling about this? > > I was going to start typing in a lengthy answer but then I remembered > I gave a tutorial at IETF70 on the choice of data formats for use in > Internet Protocols. It's centered around XML but I think covers many > of the other issues that have come up in this. Available for your > reading pleasure at http://www.tbray.org/tmp/IETF70.pdf > > -Tim > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss(a)ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg > >

1 0

Fwd: Structured data over TCP?
by Sam Johnston 27 May '09

27 May '09

We're not the only ones discussing XML vs JSON it seems... DJB's netstrings are another interesting (secure/parser friendly) approach and I reckon at least one implementation will appear which talks OCCI to nodes over protocol buffers <http://code.google.com/apis/protocolbuffers/docs/overview.html>before long. With the current proposal it doesn't matter - it's just key-value pairs and there's only so many ways you can render them which can trivially be described in the spec (e.g. "space separated text") Sam ---------- Forwarded message ---------- From: "Martin J. Dürst" <duerst(a)it.aoyama.ac.jp> Date: 2009/5/27 Subject: Re: Structured data over TCP? To: Patrik Fältström <patrik(a)frobbit.se> Cc: apps-discuss(a)ietf.org Hello Patrik, Some points, not necessarily in any particular order: - I haven't been able to figure out what the trailing ',' in netstrings is for. Any idea? - Netstrings don't say what encoding the data is in; that needs to be settled separately. XML can handle many character encodings if necessary, with sensible defaults, and there is no chance character encoding issues get forgotten. Json seems to be UTF-8 only in practice, which in most cases is about the best you can do these days. - Json's data types are closer to the data types available in many (especially dynamic) programming languages when compared with XML. XML has the advantage that it can represent both data as well as (textual) documents. The later would have to be done with a hopeless hack in Json. - Json can be directly interpreted in JavaScript. Some lazy developer may do it. But it would be an extremely bad idea, because it creates great security holes. - Both Json and XML are widely used on the Web, in what's called Ajax. But there are usually no length prefixes in either case. - There is RFC 3470 for the use of XML in the IETF. Please have a look if you haven't already done so. I'm not sure there is something similar for Json. - You say "Now, we need some more protocols here", but to me, it looks more like you want to exchange some more data. Some people might disagree, but I think there is absolutely no need to invent a new protocol every time some data has to be transferred. - Whether you call it "more protocols" or just "more data formats", if I were at either side of the data exchange, I wouldn't so much care about whether XML is easier to implement or Json or what, but I'd really hate to have a ton of different protocols/formats, each with a different technology. So unless the community involved thinks that this EPP Data Unit Format is hopelessly broken, I'd use the same scheme for all the other protocols/formats. Regards, Martin. On 2009/05/27 14:46, Patrik Fältström wrote: > It was many years ago popular to use line breaks as delimiters in data, > and on each line have essentially attribute/value pairs. > > Then we got XML that today seems to be what people want to use (because > there are libraries, and tons of programmers that can (not?) implement > XML parsers). We also have "content-length prefixed" XML data, that make > things sort of simpler. > > Sort of in parallell, we have xmlrpc, that to some degree solve slightly > different problems. > > Personally, I have lately looked at JSON, and after serializing data and > then use Netstrings (http://cr.yp.to/proto/netstrings.txt) I must say I > really like it. > > For those that do not know Netstrings, here is an example from the spec: > > For example, the string "hello world!" is encoded as <31 32 3a 68 65 >> 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The empty >> string is encoded as "0:,". >> > > Implementing is very simple, and you know how many bytes to read. An > example JSON-netstring thing can look like (for a 3-object array with a > hash as the third object, where the hash as one entry): > > 29:[1, "info", {"msg": "Hello"}], > > In the DNS provisioning world we have come up with epp (RFC 3730) that > has a binding to TCP (RFC 3734). The binding is a prefixed-based XML > blob that is passed over the wire: > > EPP Data Unit Format (one tick mark represents one bit position): >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Total Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | EPP XML Instance | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > > Now, we need some more protocols here (between DNS operator and the > registrar), and the question is whether the same mechanism is > recommended, or whether one should use something else? > > > Do Apps Area have any general feeling about this? > > Patrik > > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss(a)ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Apps-Discuss mailing list Apps-Discuss(a)ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss

1 0

Is HTTP the HTTP of cloud computing?
by Sam Johnston 27 May '09

27 May '09

And finally the conclusion: Is HTTP the HTTP of cloud computing?<http://samj.net/2009/05/is-http-http-of-cloud-computing.html>Ok so after asking Is OCCI the HTTP of cloud computing?<http://samj.net/2009/05/is-occi-http-of-cloud-computing.html>I realised that the position may have already been filled and that the question was more Is AtomPub already the HTTP of cloud computing?<http://samj.net/2009/05/is-atompub-already-http-of-cloud.html> After all my strategy for OCCI was to follow Google's example with GData by adding some necessary functionality (a search interface, caching directives, resource-specific attributes, etc.). Most of the heavy lifting was actually being done by AtomPub, thus avoiding a huge amount of tedious and error-prone protocol writing (around 20,000 words of it) - something which OGF and the OCCI working group isn't really geared up for anyway. This is clearly a workable and well-proven approach as it as been adopted strategically by both Microsoft and Google and also tactically by Salesforce and IBM, among others. Best of all adding things like queries<http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries>and versioning<http://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning>is a manageable workload while starting from scratch is most certainly not. But what if there were an easier way? Recall that the problem we are trying to solve is exposing a flexible interface to an arbitrarily large collection of interconnected compute, storage and network resources. We need to be able to describe and manipulate the resources (CRUD), associate them with each other via rich links (e.g. links with attributes like local identifiers - eth0, sda, etc.) and change their state (start, stop, restart, etc.), among other things. Representational State Transfer (REST) Actually we're not talking about exposing the resources themselves (that would be impossible) but various *representations* of those resources - like Plato's shadows on the cave walls<http://en.wikipedia.org/wiki/Allegory_of_the_cave>- this is the "REpresentational" in "REpresentational State Transfer (REST)". There's an infinite number of possible representations so it's impossible to try to capture them all now, but here's some examples: - An Open Virtualisation Format (OVF) serialisation of a compute resource - A platform-specific descriptor file (e.g. VMX) - A complete archive of the virtual machine with its dependencies (OVA) - A graphical image of the console at a given point in time ('snapshot') - A video stream of the console for archiving/audit purposes (ala Citrix's Project Iris<http://www.brianmadden.com/blogs/brianmadden/archive/2005/06/08/project-iri…> ) - The console itself (e.g. SSH, ICA, RDP, VNC) - Build documentation (e.g. PDF, ODF) - Esoteric enterprise requirements (e.g. NMS configuration) It doesn't take a rocket scientist to spot the correlation between this and HTTP's existing content negotiation functionality (whereby a client can ask for a specific representation of a given resource - e.g. HTML vs PDF) so this is already pretty much solved for us (see HTTP's Accept: header<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>for the details). For bonus points this information should be exposed in the URI as it's not always possible or convenient to set headers ala: - http://example.com/.atom (using filename extensions) - http://example.com/;content-type=text/html (using the full Internet media type) Web Linking But what about the links? As I explained yesterday<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>the web is built on links embedded in HTML documents using the A tag. Atom also provides enhanced linking functionality via the LINK element, where it is also possible to specify content types, languages, etc. In this case however we want to allow resources to be arbitrary types and more often than not we won't have the ability to link within the payload itself. This leaves us with two options: put the links in the payload anyway by relying on a meta-model like Atom (or one we roll ourselves) or find some way to represent them within HTTP itself. Enter HTTP headers which are also extensible and, as it turns out, in the process of being extended (or at least refined) to handle this very requirement by fellow down under, Mark Nottingham <http://www.mnot.net/>. See the "Web Linking" IETF Internet-Draft (draft-nottingham-http-link-header<https://datatracker.ietf.org/drafts/draft-nottingham-http-link-header/>, at the time of writing version 05<http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-05.txt>) for the nitty gritty details and the ietf-http-wg list<http://lists.w3.org/Archives/Public/ietf-http-wg/>for some <http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0211.html> current<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0196.html> discussions<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0103.html>. Basically it clarifies the existing Link: headers<http://tools.ietf.org/html/rfc2068#section-19.6.2.4>and the result looks something like this: Link: <http://example.com/TheBook/chapter2>; rel="previous"; title="previous chapter" The Link: header itself is also extensible so we can faithfully represent our model by adding e.g. the local device name when linking storage and network resources to compute resources and other requisite attributes. It would be helpful if the content-type were also specified (Atom allows for multiple links of the same relation provided the content-type differs for example) but language is already covered by HTTP (it doesn't seem useful to advertise French links to someone who already asked to speak English). It's also interesting to note that earlier versions of the HTTP RFCs actually [poorly] specified both the Link: headers<http://tools.ietf.org/html/rfc2068#section-19.6.2.4>as well as LINK <http://tools.ietf.org/html/rfc2068#section-19.6.1.2> and UNLINK<http://tools.ietf.org/html/rfc2068#section-19.6.1.3>methods for maintaining links between web resources. John Pritchard had a crack at clarification in the Efficient HyperLink Maintenance for HTTP<http://ftp.ics.uci.edu/pub/ietf/http/draft-pritchard-http-links-00.txt>I-D but like most I-Ds this one seems to have died after 6 months, and with it the methods themselves. It seems to me that adding HTTP methods at this time is a drastic (and almost certainly infeasible) action, especially for something that could just as easily be accomplished via headers ala Set-Cookie: (too bad the I-D doesn't specify how to add/delete/modify links!). In the simplest sense a Link: header appearing in a PUT or POST could replace the existing one(s) but something more elegant for acting on individual links would be nice - probably a discussion worth having on the ietf-http-wg list <http://lists.w3.org/Archives/Public/ietf-http-wg/>. Organisation of Information Looking back to Atom for a second we're still missing some key functionality: - Atom id -> HTTP URL - Atom updated -> HTTP Last-Modified: Header - Atom title and summary -> Atom/HTTP Slug: Header<http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2>or equivalent - Atom link -> HTTP Link: Header - Atom category -> ??? Houston, we have a problem. OCCI use cases range from embedded hypervisors exposing a single resource to a single entry-point for an entire enterprise or the "Great Global Grid" - we need a way to organise, categories and search for the information, likely including: - Free text search via a Google-style "?q=firewall" syntax - Taxonomy <http://en.wikipedia.org/wiki/Taxonomy> via categories (already done <http://www.ibm.com/developerworks/xml/library/x-tipatom4.html> for Atom) for things like "Operating System" and "Data Center" - Folksonomy <http://en.wikipedia.org/wiki/Folksonomy> via [user] tags (already done <http://edward.oconnor.cx/2007/02/representing-tags-in-atom> for Atom and bearing in mind that tag spaces<http://microformats.org/wiki/rel-tag#Tag_Spaces>are cool) for things like "testlab" Fortunately the good work already done in this area for Atom would be realatively easy to port to a Category: HTTP header, following the Link:header example above. In the mean time a standard search interface (including category support) is trivial and thanks to Google, already done<http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries> . Structured Data Formats HTML also resolves another pressing issue - what format to use for submitting key-value pairs (which constitutes a large part of what we need to do with OCCI). It gives us two options: - application/x-www-form-encoded<http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1>which is simple but quickly gets messy with encoding and non-ASCII characters - multipart/form-data<http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2>which is less efficient but will handle pretty much whatever you throw at it (including large files) The advantages of being able to create a resource from a web form simply by POSTing to the collection of resources (e.g. http://example.com/compute) and with HTML 5 by PUTting the resource in place directly (e.g. http://example.com/compute/<uuid>) are immediately obvious. Not only does this help make the human and programmable web one and the same (which in turn makes it much easier for developers/users to kick the tyres and understand the API) but it means that scripting even advanced tasks with curl/wget would be trivial. Plus there's no place for time-wasting religious arguments about angle brackets (XML) over curly braces (JSON). RESTful State Machines Something else which has not sat well with me until I spent the weekend ingesting RESTful Web Services <http://oreilly.com/catalog/9780596529260/>book (by Leonard Richardson <http://www.crummy.com/> and Sam Ruby<http://intertwingly.net/blog/>) was the "actuator" concept we picked up from the Sun Cloud APIs. This breaks away from RESTful principles by exposing an RPC-style API for triggering state changes (e.g. start, stop, restart). Granted it's an improvement on the alternative (GETting a resource and PUTting it back with an updated state) as Tim Bray explains in RESTful Casuistry<http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry>(to which Roy Fielding <http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post> and Bill de hÓra <http://www.dehora.net/journal/2009/02/03/just-use-post/>also responded), but it still "feels funky". Sure it doesn't make any sense to try to "force" a monitored status<http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post#comment-966>to some other value (for example setting a "state" attribute to "running"), especially when we can't be sure that's the state we'll get to (maybe there will be an error or the transition will be dependent on some outcome over which we have no control). Similarly it doesn't make much sense to treat states as nouns, for example adding a "running" state to a collection of states (even if a resource can be "running" and "backing up" concurrently). But is using URLs as "buttons" representing verbs/transitions the best answer? What makes more sense [to me] is to request a transition and check back for updates (e.g. by polling or HTTP server push<http://en.wikipedia.org/wiki/Push_technology>). If it's RESTful to POST comments to an article (which in addition to its own contents acts as a collection of zero or more comments) then POSTing a request to change state to a [sub]resource also makes sense. As a bonus these can be parametrised (for example a "resize" request can be accompanied with a "size" parameter and a "stop" request sent with clarification as to whether an "ACPI Off" or "Pull Cord" is required). Transitions that take a while, like "format" on a storage resource, can simply return HTTP 201 Accepted so we've got support for asynchronous actions as well - indeed some requests (e.g. "backup") may not even be started immediately. We may also want to consider using something like Post Once Exactly (POE)<http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt>to ensure that requests like "restart" aren't executed repeatedly and that we can cancel requests that the system hasn't had a chance to deal with yet. Exactly how this should look in terms of URL layout I'm not sure (perhaps http://example.com/<resource>/requests) but being able to enumerate the possible actions as well as acceptable parameters (e.g. an enum for variations on "stop" or a range for "resize") would be particularly useful for clients. Collections This is all well and good for individual resources, but collections are still a serious problem. There are many use cases which involve retrieving an arbitrarily large number of resources and making a HTTP request for each (as well as requests for enumeration etc.) doesn't make sense. More importantly, it doesn't scale - particularly in enterprise environments where requests via proxies and filters can suffer from high latency (if not low bandwidth). One potential solution is to strap multiple HTTP message entities together as a multipart document, but that's hardly clean and results in some hairy coding on the client side (e.g. manual manipulation of HTTP messages that would otherwise be fully automated). The best solution we currently have for this problem (as evidenced by widespread deployment) is AtomPub so I'm still fairly sure it's going to have to make an appearance somewhere, even if it doesn't wrap all of the resources by default.

5 4