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

[M. David Peterson]

On Tue, May 12, 2009 at 5:21 AM, Alexis Richardson <
alexis.richardson at 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 at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
http://broadcast.oreilly.com/m-david-peterson/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090512/8f6000ca/attachment.html