Afternoon all, The reason we want a simple API is that it be approachable. It's easier for people write to SMTP, HTTP, etc. because they can kick the tyres and learn the ropes with telnet: *$ telnet www.google.com 80*
Trying 209.85.227.103... Connected to www.l.google.com. Escape character is '^]'. *GET / HTTP/1.1* *Host: www.google.com*
HTTP/1.1 302 Found Location: http://www.google.fr/ <snip>
This is good, and a strong motivator for us to make it easy for implementors to provide a text rendering. That said it just dawned on me that with both Microsoft and Google (among others) strategically backing AtomPub, it will be impossible to claim with a straight face to be a cloud developer if you don't know it yourself. IOW, cloud developers will already necessarily have exposure to, and in many cases intimate knowledge of, AtomPub. Regardless of how simple our simple protocol is, everyone's going to be starting from scratch. Yet again oversimplification could well raise the bar... we need to be as simple as possible but no more. Whatever we do we need to make sure the very first step is as low as possible. Sam
Sam Johnston wrote:
The reason we want a simple API is that it be approachable. It's easier for people write to SMTP, HTTP, etc. because they can kick the tyres and learn the ropes with telnet:
I absolutely agree with this, but regard it as an argument in favour of POJ/POX over AtomPub. I think we're agreed that a text rendering would be good to have, but will be an optional supporting format for integration, at best. That means that I'm also interested in making the core format approachable and something with which people can kick the tyres and learn the ropes using telnet. My feeling is that a POJ/POX rendering is a smaller amount of JSON/XML with less wrapping around it, and will be much easier for people to get to know by hand. Richard.
On Mon, May 18, 2009 at 11:07 AM, Richard Davies < richard.davies@elastichosts.com> wrote:
Sam Johnston wrote:
The reason we want a simple API is that it be approachable. It's easier for people write to SMTP, HTTP, etc. because they can kick the tyres and learn the ropes with telnet:
I absolutely agree with this, but regard it as an argument in favour of POJ/POX over AtomPub.
<snip>
My feeling is that a POJ/POX rendering is a smaller amount of JSON/XML with less wrapping around it, and will be much easier for people to get to know by hand.
It's still something new though so you have that initial hurdle. By throwing their weight behind it, Microsoft and Google have ensured that AtomPub will be essential knowledge for cloud developers anyway. IOW an AtomPub based protocol will be significantly easier to pick up than anything you might concoct yourselves (and I say "you yourselves" because it's overwhelmingly unlikely that I'll be playing a part in it for reasons previously explained). *AtomPub is already the HTTP of cloud computing IMO* - it just needs some specification around search, caching, embedding, extension, etc. and it'll be everything we'll ever need and (not much) more. Sam
Richard Davies wrote:
My feeling is that a POJ/POX rendering is a smaller amount of JSON/XML [than AtomPub] with less wrapping around it
Sam Johnston wrote in a separate thread:
IOW, your average [AtomPub] request to ElasticHosts is going to be skeletal while your average request to VMware (if they ever implement it) will be relatively fat. Who cares?
This is something which I love to understand better - how skeletal the minimum AtomPub request can be. This would help me to understand how much "weight" which we are taking on comparing AtomPub vs. POX/POJ. Sam - can you help me work this out - I've started below... As a thought experiment, consider starting from a POX rendering of the nouns, verbs and attributes in the style of my second example at: http://www.ogf.org/pipermail/occi-wg/2009-May/000526.html with the same URLs and verb behaviours as I'd proposed at: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/SimpleJSONRen... This is already (and deliberately) somewhat in the style of AtomPub. For example, the noun endpoints are similar and my <object> tags contain roughly the same as the AtomPub <entry> tags would. Now compare this with a minimal AtomPub such as: http://occitest.appspot.com/ What is the set of changes I need to make to get from this POX to the minimum AtomPub? Assume for this thought experiment that I don't want to benefit from any additional services which AtomPub provides, but just want the same experience as with the POX rendering. I can name a few: - There's a <feed> tag which wraps all of the entries/objects. It has various other subtags of its own (e.g. title, subtitle, author). Am I right that all of these are static and could be bolted on by a server or ignored by a client which skips straight to the entries? - Am I right that this <feed> tag is only relevant when getting the entire overall feed? When inserting or updating individual entries we still send the entry alone. - There are 'updated' tags on every entry. Can these be ignored by clients and set to the current time by servers? - All UUIDs are prefixed by urn:uuid: - Each entry has a link confirming its own end point (versus the POX rendering just defines fixed end points for objects). - Each entry will have links confirming all of its actuators (versus the POX rendering just defines a fixed URL scheme for the actuators). - The syntax for linking one noun to another is different, and additionally specifies a schema for the link (defined as fixed in the direct rendering). - I believe that the nouns' attributes will end up inside a <content> tag inside the entry, rather than being at the top level. - A HTTP DELETE call has to specify an ETag version as part of a delete call Is that list correct? What else is there?
On Mon, May 18, 2009 at 1:23 PM, Richard Davies < richard.davies@elastichosts.com> wrote:
Richard Davies wrote:
My feeling is that a POJ/POX rendering is a smaller amount of JSON/XML [than AtomPub] with less wrapping around it
Sam Johnston wrote in a separate thread:
IOW, your average [AtomPub] request to ElasticHosts is going to be skeletal while your average request to VMware (if they ever implement it) will be relatively fat. Who cares?
This is something which I love to understand better - how skeletal the minimum AtomPub request can be. This would help me to understand how much "weight" which we are taking on comparing AtomPub vs. POX/POJ.
Sam - can you help me work this out - I've started below...
Ok, very happy to see this progress to specific technical questions...
<snip> What is the set of changes I need to make to get from this POX to the minimum AtomPub? Assume for this thought experiment that I don't want to benefit from any additional services which AtomPub provides, but just want the same experience as with the POX rendering.
- Your object element becomes an entry - If you have multiple entries you wrap them in a feed - Atom categories are very flexible - you can have multiple namespaces for a start (e.g. resource types vs operating systems vs user tags) - but otherwise they're pretty close - Attributes go into namespaces - I see this as a feature, not a bug, as it makes what you're talking about clear. For example, compute:cores, memory:size, memory:speed - Links are generic (who says it's IDE anyway... what about [i]SCSI?) As you can see most of the changes are superficial. I can name a few:
- There's a <feed> tag which wraps all of the entries/objects. It has various other subtags of its own (e.g. title, subtitle, author). Am I right that all of these are static and could be bolted on by a server or ignored by a client which skips straight to the entries?
Yup, and the wrapping feed is optional.
- Am I right that this <feed> tag is only relevant when getting the entire overall feed? When inserting or updating individual entries we still send the entry alone.
Yup.
- There are 'updated' tags on every entry. Can these be ignored by clients and set to the current time by servers?
Yes, but while it's ok to ignore them client side if you don't need them, giving accurate information on the server side will allow clients to make optimisations. That is, it will work if you don't, but nothing will ever be cached.
- All UUIDs are prefixed by urn:uuid:
Yup, they have to be URIs per Atom. That's OK by me - I think there's lots of advantages in enforcing use of UUIDs but there's alternatives like the tag: namespace and who knows what other resources will need to be modeled in future?
- Each entry has a link confirming its own end point (versus the POX rendering just defines fixed end points for objects).
Entries don't have to be ephemeral - that is, you might be retrieving it from a queue, file, cache etc. and it's useful to know where you can find the latest version.
- Each entry will have links confirming all of its actuators (versus the POX rendering just defines a fixed URL scheme for the actuators).
All the URLs we're going to use should be advertised via the protocol - configuring only a single entry point makes a lot of sense. It's also necessary for HATEOAS - that is, advertising what states and transitions are reachable. Templates might be cloneable but not startable for example, and we don't know what the future holds in terms of new states/transitions.
- The syntax for linking one noun to another is different, and additionally specifies a schema for the link (defined as fixed in the direct rendering).
Yup, links can be used to link whatever you like to whatever you like. If your network needs to point at an NMS in the form of a compute resource then fine.
- I believe that the nouns' attributes will end up inside a <content> tag inside the entry, rather than being at the top level.
This is something of a religious debate and something that Atom purists would probably agree with you on. That said, there's nothing stopping us from putting this stuff at the root and leaving the content element for e.g. an [X]HTML rendering. In fact you can replace the content element with a link element if you want.
- A HTTP DELETE call has to specify an ETag version as part of a delete call
No, but it's safer to do so (e.g. so you don't delete a resource that has changed since you retrieved it). It's fine if you don't, but implementations could in theory reject your request.
Is that list correct? What else is there?
Let me know as you come up with more questions - I have to go get ready for an early flight to the Cloud Computing Expo in London (see some of you there). Sam
Sam Johnston wrote:
Is that list correct? What else is there?
Let me know as you come up with more questions
OK - so I'm glad that my identified points of difference were almost all correct and mostly rearrangements (which each make it more ugly and heavy than the POX in my view, but are admittedly individually small steps). My question was really about my "unknown unknowns" - i.e. is that set of differences complete, or are there other things which have to be added. I'm not enough of an AtomPub expert to write a longer fuller list and believe it is complete, but I'm sure that someone on this list is! What other point of difference from POX are there which I missed which AtomPub would require in either the server or the client in order to be compliant? Cheers, Richard.
participants (2)
-
Richard Davies -
Sam Johnston