[occi-wg] Microsoft: "Atom Publishing Protocol (AtomPub) as the future direction"

[Sam Johnston]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090512/b0b3639a/attachment.html