Microsoft: "Atom Publishing Protocol (AtomPub) as the future direction"
Afternoon all, I'm surprised this slipped by before but while re-reading Joe Gregorio's recent controversial rant <http://bitworking.org/news/425/atompub-is-a-failure> on AtomPub I spotted this comment<http://bitworking.org/news/425/atompub-is-a-failure#X2>which explains:
Microsoft is migrating all of its Live Services APIs<http://msdn.microsoft.com/en-us/library/bb264574.aspx>into a single unified AtomPub API in the Live Framework <http://dev.live.com/liveframework/>. It appears they will also open up the ability for third parties to do the same.
I don't think the JSON argument is such a big deal. Google Data APIs support output in JSON and RSS formats. Microsoft's Live Framework supports full CRUD with JSON, AtomPub, and POX, as well as output in RSS. Under the hood, they are simply offering a JSON encoding of AtomPub.
Interesting choice of "POX" as in "Plain Old XML", thus avoiding the XML-RPC/SOAP stigma... but we digress... this post<http://dev.live.com/blogs/devlive/archive/2008/02/27/213.aspx>from a Microsoft VP leaves little to the imagination:
Atom Publishing Protocol (AtomPub) as the future direction
Microsoft is making a large investment in unifying our developer platform protocols for services on the open, standards-based Atom format (RFC 4287<http://www.ietf.org/rfc/rfc4287.txt>) and the Atom Publishing Protocol (RFC 5023<http://www.ietf.org/rfc/rfc5023.txt> ). At MIX we are enabling several new Live services with AtomPub endpoints which enable any HTTP-aware application to easily consume Atom feeds of photos and for unstructured application storage (see below for more details). Or you can use any Atom-aware public tools or libraries, such as .NET WCF Syndication <http://msdn2.microsoft.com/en-us/library/bb412202.aspx>to read or write these cloud service-based feeds.<snip>
The intent for these early, experimental releases are to gather valuable feedback from the community around our idiomatic and freely licensed extensions to AtomPub which deal with important service scenarios, such as URL formats, nested directories, image streams, and service metadata. You can read more about this on the Project Astoria team blog<http://blogs.msdn.com/astoriateam/archive/2008/02/13/atompub-support-in-the-ado-net-data-services-framework.aspx> .
The developer docs <http://msdn.microsoft.com/en-us/library/dd137315.aspx>further explain:
AtomPub was chosen as the base-level interaction protocol for CRUD operations on Live Framework resources. Using a community-supported interpretation of Representational State Transfer (REST) and its interaction model for exchanging feed-based representations enables a variety of basic AtomPub clients, applications, and tools to interact with the Live Framework.
It's worth noting that in a "big switch in direction" and "huge endorsement for AtomPub " "Microsoft dropp[ed] Web3S for AtomPub for Windows Live! service APIs<http://www.xlml.com/aehso/2008/02/29/microsoft-dropping-web3s-for-atompub-for-windows-live-service-apis/>". This is interesting because it was a move from away from a "simple XML" type rendering (example <http://dev.live.com/livedata/web3s.htm#_Toc165288985>) previously proposed here for OCCI towards AtomPub with a light, standardised structure. Apparently Salesforce are getting in on the game too, at least in so far as their integrations with Google<http://wiki.developerforce.com/index.php/Google_Data_API_Toolkit>go. According to Bill de hÓra<http://www.dehora.net/journal/2008/06/24/salesforcecom-and-google-integration-atompub/> :
One upside is that adopting Atom protocol<http://wiki.apexdevnet.com/index.php/Google_Data_API_Toolkit>and the associated HTTP-like-it-oughta-be approach a should help salesforce.com stop creating multiple incompatible APIs on top of the many (~18?) they have already (apparently these APIs account for 45% of sf.com's transactions). Or at least slow that kind of unneccessary churn down.
Salesforce's API has been around for so long that it's still SOAPy but I would not be surprised to see this change at some point... an open standard that delivers the extensions that Google and Microsoft felt necessary to add could well be all it takes to get them on board too (while they don't offer infrastructure, they do offer platform services and that's the logical progression for OCCI). Sam
Sam, That's a great spot - thanks for posting it. I'm not convinced that MS claims for 'REST' stand up under scrutiny, but it is interesting to see AtomPub getting a boost. I thought this was quite interesting too: http://www.defuze.org/archives/171-atom-and-atompub-were-failed.html a On Tue, May 12, 2009 at 12:01 PM, Sam Johnston <samj@samj.net> wrote:
Afternoon all,
I'm surprised this slipped by before but while re-reading Joe Gregorio's recent controversial rant on AtomPub I spotted this comment which explains:
Microsoft is migrating all of its Live Services APIs into a single unified AtomPub API in the Live Framework. It appears they will also open up the ability for third parties to do the same.
I don't think the JSON argument is such a big deal. Google Data APIs support output in JSON and RSS formats. Microsoft's Live Framework supports full CRUD with JSON, AtomPub, and POX, as well as output in RSS. Under the hood, they are simply offering a JSON encoding of AtomPub.
Interesting choice of "POX" as in "Plain Old XML", thus avoiding the XML-RPC/SOAP stigma... but we digress... this post from a Microsoft VP leaves little to the imagination:
Atom Publishing Protocol (AtomPub) as the future direction
Microsoft is making a large investment in unifying our developer platform protocols for services on the open, standards-based Atom format (RFC 4287) and the Atom Publishing Protocol (RFC 5023). At MIX we are enabling several new Live services with AtomPub endpoints which enable any HTTP-aware application to easily consume Atom feeds of photos and for unstructured application storage (see below for more details). Or you can use any Atom-aware public tools or libraries, such as .NET WCF Syndication to read or write these cloud service-based feeds.<snip>
The intent for these early, experimental releases are to gather valuable feedback from the community around our idiomatic and freely licensed extensions to AtomPub which deal with important service scenarios, such as URL formats, nested directories, image streams, and service metadata. You can read more about this on the Project Astoria team blog.
The developer docs further explain:
AtomPub was chosen as the base-level interaction protocol for CRUD operations on Live Framework resources. Using a community-supported interpretation of Representational State Transfer (REST) and its interaction model for exchanging feed-based representations enables a variety of basic AtomPub clients, applications, and tools to interact with the Live Framework.
It's worth noting that in a "big switch in direction" and "huge endorsement for AtomPub " "Microsoft dropp[ed] Web3S for AtomPub for Windows Live! service APIs". This is interesting because it was a move from away from a "simple XML" type rendering (example) previously proposed here for OCCI towards AtomPub with a light, standardised structure.
Apparently Salesforce are getting in on the game too, at least in so far as their integrations with Google go. According to Bill de hÓra:
One upside is that adopting Atom protocol and the associated HTTP-like-it-oughta-be approach a should help salesforce.com stop creating multiple incompatible APIs on top of the many (~18?) they have already (apparently these APIs account for 45% of sf.com's transactions). Or at least slow that kind of unneccessary churn down.
Salesforce's API has been around for so long that it's still SOAPy but I would not be surprised to see this change at some point... an open standard that delivers the extensions that Google and Microsoft felt necessary to add could well be all it takes to get them on board too (while they don't offer infrastructure, they do offer platform services and that's the logical progression for OCCI).
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Tue, May 12, 2009 at 5:21 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
I thought this was quite interesting too: http://www.defuze.org/archives/171-atom-and-atompub-were-failed.html
It goes deeper than this, and to some degree both Joe and Sylain -- two folks I am privileged enough to consider close friends -- are both correct. AtomPub wasn't designed from the standpoint of creating a browser-centric publishing protocol, and instead an HTTP-centric publishing protocol. In fact one could argue that web browsers as they exist today are completely incompatible with AtomPub for the simple fact that they lack full support of the HTTP verbs used as the centralized focus for AtomPub, namely GET, POST, PUT, and DELETE. In this regard, Joe's point is spot on: It's not that browsers have made drastic technological advances in the last seven years, and instead hackers like you and I have discovered there was more power under the hood than we all initially realized (Credit IE and the XmlHttpRequest object), began to use this power in new and innovative ways, and the browser vendors have since followed suit by taking the XmlHttpRequest object, fine tuning the API, standardizing it, to then implement that standard in varying degrees of compatibility. The end result of all of this is that browsers have a clearly defined and adequately supported standard for pushing information from client to server and back again in a way that works well /IF/ you're looking at things strictly from a browsers perspective, the most ubiquitous application on the planet. In other words, if you want to build an application with the greatest potential reach, building it inside the confines of a browser makes a lot of sense. And it's because of this that the web browser has developed a /MUCH/ longer life expectancy as far as an application platform is concerned. But again, AtomPub wasn't designed from the stand point of the browser being the primary publishing tool. It was designed as a cross-platform, cross-device HTTP-centric publishing protocol in which any application capable of speaking HTTP could Create, Read, Update, and Delete resources on any AtomPub compliant server they had suficient access and privs to. The fact that most browsers are incompatible with AtomPub isn't something that anyone should look at as a dagger through the heart of AtomPub. In fact, quite the opposite: The browser vendors need to catch up with the rest of the devices and applications out there which speak fluent HTTP 1.1 if they are to ever be looked upon as true application frameworks instead of the lowest common denominator in which the likes of Flash, Silverlight, Google Gears, and other forms of in-browser application frameworks use as little more than a delivery vessel to push their state of the art while browser vendors seem complacent on pushing the state of the article tag and calling that progress. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/
On Tue, May 12, 2009 at 7:57 AM, M. David Peterson <xmlhacker@gmail.com>wrote:
On Tue, May 12, 2009 at 5:21 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
I thought this was quite interesting too: http://www.defuze.org/archives/171-atom-and-atompub-were-failed.html
It goes deeper than this, and to some degree both Joe and Sylain
You'd think the fact that Syl/v/ain and I have been friends for more years than I have fingers and toes to keep track of, and have even lived under the same roof for a period of time would keep me from mistakenly leaving the 'v' out of his name. Sorry 'bout that Sylvain! :-) -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/
On Tue, May 12, 2009 at 7:57 AM, M. David Peterson <xmlhacker@gmail.com>wrote:
The browser vendors need to catch up with the rest of the devices and applications out there which speak fluent HTTP 1.1
I should clarify this statement: From an internal perspective, very few web browsers don't speak fluent HTTP 1.1. They may each interpret the spec just a tad bit differently, and they've certainly been known to leave out support for critical pieces such as -- oh, I don't know, ETags for example! ;-) Where they fall short is exposing that support at the API level in a consistent, cross browser manner. This is just my own opinion, of course, but if the HTML5 WG /REALLY/ wanted to make a difference they'd stop trying to agree upon defining element names and definitions which can just as easily be implemented via the 'object/@type' element/attribute combination** , and instead use their time to first, come to terms with how to expose full client/server support for the HTTP 1.1 spec to the developer such that each node on the net is both a client /AND/ a server, to then establish a formalized process for introducing additional protocols into the mix that have proven to be of value to a broader swath of developers (XMPP anyone? BitTorrent? AtomPub? Kermit? ;-)) and are therefore candidates for finding their way into the toolbags of /ALL/ developers and usable by /ALL/ folks who just so happen to have a communication protocol standards compliant web browser installed on their machine. A man can dream, can't he! ;-) ** okay, that's obviously a stretch, but what's the difference between agreeing upon a common set of param/@name child elements and defining attribute names for a 'video' element? Answer: One less element to have to kill off in 10 years when holograms become all the rage and the video element goes the way of the blink element. ;-) -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/
List this is OT but may be of just enough interest to those following David's emails, that I am going to cc occi-wg. David, Check out: http://www.reversehttp.net/reverse-http-spec.html It's a way to make each node be a server and a client. Built by one of our lot. alexis On Tue, May 12, 2009 at 3:58 PM, M. David Peterson <xmlhacker@gmail.com> wrote:
On Tue, May 12, 2009 at 7:57 AM, M. David Peterson <xmlhacker@gmail.com> wrote:
The browser vendors need to catch up with the rest of the devices and applications out there which speak fluent HTTP 1.1
I should clarify this statement: From an internal perspective, very few web browsers don't speak fluent HTTP 1.1. They may each interpret the spec just a tad bit differently, and they've certainly been known to leave out support for critical pieces such as -- oh, I don't know, ETags for example! ;-)
Where they fall short is exposing that support at the API level in a consistent, cross browser manner.
This is just my own opinion, of course, but if the HTML5 WG /REALLY/ wanted to make a difference they'd stop trying to agree upon defining element names and definitions which can just as easily be implemented via the 'object/@type' element/attribute combination** , and instead use their time to first, come to terms with how to expose full client/server support for the HTTP 1.1 spec to the developer such that each node on the net is both a client /AND/ a server, to then establish a formalized process for introducing additional protocols into the mix that have proven to be of value to a broader swath of developers (XMPP anyone? BitTorrent? AtomPub? Kermit? ;-)) and are therefore candidates for finding their way into the toolbags of /ALL/ developers and usable by /ALL/ folks who just so happen to have a communication protocol standards compliant web browser installed on their machine.
A man can dream, can't he! ;-)
** okay, that's obviously a stretch, but what's the difference between agreeing upon a common set of param/@name child elements and defining attribute names for a 'video' element? Answer: One less element to have to kill off in 10 years when holograms become all the rage and the video element goes the way of the blink element. ;-) -- /M:D
M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/
On Tue, May 12, 2009 at 9:42 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
List this is OT but may be of just enough interest to those following David's emails, that I am going to cc occi-wg.
David,
Check out: http://www.reversehttp.net/reverse-http-spec.html
It's a way to make each node be a server and a client. Built by one of our lot.
Interesting. Given this conversation extended from one of Sylvain's posts, and given that Sylvain happens to be one of the editors on the LLUP specification, and given that LLUP -- at first glance, anyway -- seems to blend nicely with the reverse-http spec linked to above, and -- just to add one more layer of "given that" into the mix -- given that LLUP is built firmly on top of both Atom and AtomPub, I've CC'd the LLUP working group as well. For those of you wondering what LLUP is in reference to, see: http://dev.llup.org/ < I bring this up as depending on the use case, LLUP /could/ in various forms and capacities be used to manage messaging pub/sub workflows in a decentralized, heterogeneous cloud environment. In fact, an interesting and related use case provided by Tim Lynch from Cornell University can be found @ http://groups.google.com/group/llup/browse_thread/thread/76411666bb2e7542/8f... -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/
Hi All,
On Tue, May 12, 2009 at 9:42 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
List this is OT but may be of just enough interest to those following David's emails, that I am going to cc occi-wg.
David,
Check out: http://www.reversehttp.net/reverse-http-spec.html
It's a way to make each node be a server and a client. Built by one of our lot.
Interesting. Given this conversation extended from one of Sylvain's posts, and given that Sylvain happens to be one of the editors on the LLUP specification, and given that LLUP -- at first glance, anyway -- seems to blend nicely with the reverse-http spec linked to above, and -- just to add one more layer of "given that" into the mix -- given that LLUP is built firmly on top of both Atom and AtomPub, I've CC'd the LLUP working group as well.
For those of you wondering what LLUP is in reference to, see: http://dev.llup.org/ < I bring this up as depending on the use case, LLUP /could/ in various forms and capacities be used to manage messaging pub/sub workflows in a decentralized, heterogeneous cloud environment. In fact, an interesting and related use case provided by Tim Lynch from Cornell University can be found @ http://groups.google.com/group/llup/browse_thread/thread/76411666bb2e7542/8f...
I wasn't aware of Reverse HTTP. It looks quite interesting and I'm surprised we haven't heard more of it yet. Just as reminder for those who didn't follow, LLUP is a simple messaging format which focuses on making each message as stateless as possible while carrying contextual information that would allow any recipient to consume, interpret and perform intelligent actions on each message. This is obviously particularly suited to the cloud since each node within doesn't really need to know nor even care how the message arrived. It just sees a message, deals with it and pushes another message to the cloud. Like David said: decentralized, heterogeneous cloud environment. In that context, Reverse HTTP is rather interesting to transport LLUP messages since LLUP doesn't care about this aspect. As far as it goes you could use HTTP, XMPP or pigeons. The only important aspect from LLUP's perspective is the fact the message is in the cloud and some node will pick it up. - Sylvain -- Sylvain Hellegouarch http://www.defuze.org
Sylvain - thanks! I'm cc'ing Tony who wrote the reverse http spec. I suspect this is now OT for OCCI, but please continue directly, or if enough OCCI-WG people are interested, on-list. alexis On Wed, May 13, 2009 at 8:53 AM, Sylvain Hellegouarch <sh@defuze.org> wrote:
Hi All,
On Tue, May 12, 2009 at 9:42 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
List this is OT but may be of just enough interest to those following David's emails, that I am going to cc occi-wg.
David,
Check out: http://www.reversehttp.net/reverse-http-spec.html
It's a way to make each node be a server and a client. Built by one of our lot.
Interesting. Given this conversation extended from one of Sylvain's posts, and given that Sylvain happens to be one of the editors on the LLUP specification, and given that LLUP -- at first glance, anyway -- seems to blend nicely with the reverse-http spec linked to above, and -- just to add one more layer of "given that" into the mix -- given that LLUP is built firmly on top of both Atom and AtomPub, I've CC'd the LLUP working group as well.
For those of you wondering what LLUP is in reference to, see: http://dev.llup.org/ < I bring this up as depending on the use case, LLUP /could/ in various forms and capacities be used to manage messaging pub/sub workflows in a decentralized, heterogeneous cloud environment. In fact, an interesting and related use case provided by Tim Lynch from Cornell University can be found @ http://groups.google.com/group/llup/browse_thread/thread/76411666bb2e7542/8f...
I wasn't aware of Reverse HTTP. It looks quite interesting and I'm surprised we haven't heard more of it yet.
Just as reminder for those who didn't follow, LLUP is a simple messaging format which focuses on making each message as stateless as possible while carrying contextual information that would allow any recipient to consume, interpret and perform intelligent actions on each message.
This is obviously particularly suited to the cloud since each node within doesn't really need to know nor even care how the message arrived. It just sees a message, deals with it and pushes another message to the cloud. Like David said: decentralized, heterogeneous cloud environment.
In that context, Reverse HTTP is rather interesting to transport LLUP messages since LLUP doesn't care about this aspect. As far as it goes you could use HTTP, XMPP or pigeons. The only important aspect from LLUP's perspective is the fact the message is in the cloud and some node will pick it up.
- Sylvain -- Sylvain Hellegouarch http://www.defuze.org
On Wed, May 13, 2009 at 2:30 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
Sylvain - thanks! I'm cc'ing Tony who wrote the reverse http spec.
I suspect this is now OT for OCCI, but please continue directly, or if enough OCCI-WG people are interested, on-list.
Just want to quickly jump in and point out the fact that while I'm excited to take part in this particular discussion, I'm away all morning and throughout most of the afternoon (based on MDT) so it will be a while before I'm able to chime back in. None-the-less, looking forward to jumping in head first upon my return. NOTE: We should probably take OCCI off and encourage those who'd like to follow along and/or join in to join the conversation via the LLUP group @ http://groups.google.com/group/llup -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/
On May 12, 2009, at 4:21 AM, Alexis Richardson wrote:
Sam,
That's a great spot - thanks for posting it.
I'm not convinced that MS claims for 'REST' stand up under scrutiny, but it is interesting to see AtomPub getting a boost.
I thought this was quite interesting too: http://www.defuze.org/archives/171-atom-and-atompub-were-failed.html
I'm reasonably happy with AtomPub's progress, and think it will continue to do OK. If I were paranoid and cynical, I would point out that anyone who offers users AtomPub access to their data has given up the ability to lock them in, and that this might be part of the explanation why lots of services aren't yet. -Tim
participants (5)
-
Alexis Richardson -
M. David Peterson -
Sam Johnston -
Sylvain Hellegouarch -
Tim Bray