I’ve Seen This Movie

Search

It turns out that the Atom Protocol isn’t good enough for whatever
part of Microsoft Dare Obasanjo works in,
he
says. Three things should be said: First, Dare’s arguments are bogus.
Second, if you were paranoid and cynical, you might
wonder what Microsoft’s up to (I’m paranoid and cynical.)
Finally, this is actually good news.
[Update: Check out
Dare’s
GData isn't a Best Practice Implementation of the Atom Publishing Protocol
and Microsoft and the Atom Publishing Protocol,
and especially Joe Cheng’s
Microsoft is not sabotaging APP (probably).
It looks like Microsoft will be joining the APP
party after all; excellent! On GData: as of April’s interop event,
GData, based on an early draft of the APP, was far from being an interoperable
drop-in implementation. But that’s what the event was for; Kyle
Marvin and the Googlers gathered tons of hands-on data and, last time I
checked, still say they intend to do APP straight-up.]

He’s Wrong ·
Joe Gregorio covers most of the territory:
In which we narrowly save Dare from inventing his own publishing protocol.
Dare’s claim that APP doesn’t cover the synchronization problem is really
egregious and establishes that he doesn’t actually understand APP (no
surprise, he hasn’t participated in the WG since 2005 and didn’t take the
trouble to come to the interop meeting).
When one of his commenters pointed this out he harumphed “Of
course, I haven't found any Atom servers or other RESTful Web service
implementations that support this in the wild but that doesn't mean it isn't
possible” which I
would translate as “What I said was completely wrong”.

But what made my blood pressure threaten to squirt out my
ears was the line about re-inventing WebDAV poorly, repeated in the
comments. This is cluelessness on a Napoleonic scale, establishing that Dare
doesn’t actually understand the key difference between APP and WebDAV (In APP,
the server takes care of navigating the URI space; in WebDAV, the client owns
the problem.)
WTF!?!?

So, while APP might not work for some part
of Microsoft, it won’t be for Dare’s reasons.
One would assume that the world’s largest software company, when facing a
technology choice, would take the trouble to actually, you know,
understand the technologies involved, but the evidence doesn’t
support that assumption.

Why? ·
The thing is, I’ve seen this movie before: The movie where there’s an
emerging standard that’s got some buzz and looks promising and maybe it’ll
raise the tide and float all our boats a little higher, and then Microsoft
says they won’t play.

Since there are huge numbers of computers out there with Microsoft client
software, APP-enabling those clients would definitely lift the tide.
But then, of course, the people using those computers would be able to post to
any old online property they want to. As opposed to just
Spaces. By the way, Dare has spent
quite a bit of time on the Spaces team.

Do I believe that Microsoft would deliberately steer their client
implementations away from APP and toward something else that Windows Live
Spaces would have the first and perhaps only implementation of? Well,
um... yes.

But I wouldn’t sweat it too much. Microsoft has tried to swim against the
current of the Internet a few times before, and it’s basically never
worked. So they can go and invent their own publishing protocol and that’s
sad, because it’ll be wasted work. Oh well, shit happens.

This Isn’t Bad News ·
There’s another movie I’ve seen before. It’s the movie where an interesting
new protocol or interface or API comes along, is starting to get adoption,
and big incumbent vendors say “That’s too simple for our needs”. Examples of
such technologies include Unix, C, SQL, Java, and RSS:
the kinds of technologies that end
up winning. (I’ve written about this before in the
TPSM
series:
The 80/20
Point).

There are places (network TV, Middle Eastern politics) where cluelessness
regularly triumphs. Internet protocols aren’t one of them. Sorry, Dare.
And this kind of movie usually has a happy ending.

last section, "On Strategy Tax". I expect to see this happen more than once in the Web2.0 space, and not just with protocols. It follows naturally from people like Tim O'Reilly's observations that data is the new platform. That's ok; like you said, things will work out.

This is interesting. While MS - at the level where technology decisions are made & acted upon - fairly blatantly continues to provide tangible examples of anti-competitive behavior (the very kind that the consent decree is purported to prohibit), you have the company spending $55MM lobbying Washington, often in front of ex-MS employees, lobbyists or legal counsel now in the position to rule on new complaints.

Shades of Netscape, I say (as have others). Is MS trying to make non-MS technology work less well on their platform? Almost without doubt. Can I prove it? Not really, but then why would I need to when silliness like this w/ Dare continues?

Microsoft never (read very rarely) makes a technology choice based on technical merits alone. The driving force behind any choice made within Microsoft is, most likely, non-technical. Only time will tell, but I am with you in that I am confident that the market will make the correct choice.

What is it about web syndication formats and protocols that gets otherwise calm and rational people so worked up? Dare's post on Friday seemed to be saying (in moderate language, especially by his's standards) that his team was making a good faith effort to leverage APP for a scenario that was a bit outside its mainstream use cases, and were having problems. "Gregor Rothfuss wondered whether I couldn't influence people at Microsoft to also standardize on GData. The fact is that I've actually tried to do this with different teams on multiple occasions and each time the I've tried, certain limitations in the Atom Publishing Protocol become quite obvious when you get outside of blog editing scenarios for which the protocol was originally designed."

Considering that APP is still a draft spec, I would think the reasonable response options for stakeholders receiving what amounts to a bug feport would be along the lines of a) show Dare how to use the spec to do what he needs to do, b) modify the spec based on real-world feedback to ensure that it meets this use case, or c) modify the spec to clarify that the use case is out of scope. Instead, the responses were full of rhetorical flourishes questioning his motives, timing, and intelligence, not to mention greatly overstating his point. ("Why GData/APP Fails as a General Purpose Editing Protocol for the Web " -> "APP on the Web has failed: miserably, utterly, and completely" ???)

I find the non-response to his third point about APP's unsuitability for hierarchical data particularly disappointing. Joe Gregorio just says "gloves", referring to http://worsethanfailure.com/Articles/The_Complicator_0x27_s_Gloves.aspx). You (Tim) deflect it by noting that technologies that hit the 80/20 point generally win. I can only point out that it's not clear that APP hits the 80/20 point non-blog editing scenarios; it *is* clear that a major cause of software project failure is unacceptable performance, so simply noting breaking up deeply hierarchical representations and linking to their components may not work for other scenarios; and those once-simple technologies such as SQL and Unix turned into hairballs once they had to address the last 20% of the use cases. The question here isn't whether APP has utterly failed for the 80% case, it's whether it is suitable IN ITS CURRENT FORM for some extended cases (Facebook and GData were mentioned). I have no idea whether it is or not, but the APP side has shed a lot more heat than light on the question Dare posed.

Finally, I find it very interesting that this parallels a discussion in the web services world, where WS-Transfer was devised to provide REST-friendly functionality in environments where HTTP doesn't exist. The question soon arose of how to deal with very large resource representations where it would be inefficient to get the whole thing, modify a fragment, and put the whole thing back. HTTP doesn't offer a model for how to address this. Various specs -- some in the WSDM stack that IBM but not MS supports, and WS-ResourceTransfer in the roadmap for unifying them (what Dave Orchard http://www.pacificspirit.com/blog/2006/04/04/wssopranosdesperatehousewiveskwisatchhaderach calls WS-KwisatchHaderach) -- take a stab at allowing fragment level retrieval/update. There's no well-established solution to the problem, but there is a widespread recognition that some solution to the partial representation update challenge is needed.

This same issue has plagued the XML database world from the beginning, and the XQuery 1.0 standard doesn't address it. The fact that it keeps popping up wherever large XML resource representations appear in the real world suggests to me that it's a real problem in APP's extended domain as well.

I think he is one of the most interesting voices from the confines of MS-land. Although provocative, I think his "early adopter exploration" was particular informative and that APP came out of it well.

<blockquote>The fact that it keeps popping up wherever large XML resource representations appear in the real world suggests to me that it's a real problem in APP's extended domain as well.</blockquote>

I find it odd that you lay out the facts showing that this will be a problem completely independently of what protocol is chosen, and then use that to defend that Dare’s conclusion that it must therefore be a problem with APP. APP is a red herring.

<blockquote>Instead, the responses were full of rhetorical flourishes questioning his motives, timing, and intelligence, not to mention greatly overstating his point.</blockquote>

Sorry, I don’t buy your “instead”.

*All* of the responses I saw concentrated foremost on debunking Dare’s arguments; *only* Tim spent any significant amount of his post questioning Dare’s motives. *Everyone* pointed out how AtomPP applies to Dare’s case for the one complaint where such advice could reasonably be given.

What are you trying to achieve here by painting everyone with the conspirationist brush?

Then again, it *is* hard to avoid the rhetorical flourishes when the arguments are so transparently bogus. Dare’s “WebDAV reinvented poorly” quip in particular is utter garbage; if he *really* means it, he understands neither WebDAV nor AtomPP. But Dare being stupid doesn’t seem like a reasonable conclusion – so how do you expect people not to look for alternative explanations?

<blockquote>What is it about web syndication formats and protocols that gets otherwise calm and rational people so worked up?</blockquote>

I don’t know, but after this opening, I wonder how you work up the nerve to take everyone to task for rhetorical flourishes.

It's the disingenuous partial quoting that doesn't do you any favors. My actual words are duplicated below so everyone has a basis to judge:

"""Again, what we have here is a complaint about the format and not the protocol, as this applies just as well to syndication as it does to authoring. And yes, that's the way Atom the syndication format, and the protocol, represent relationships between items, via links. One simple, consistent, easy to explain mechanism, as opposed to a hybrid approach of allowing linking and inline inclusion, because even if you allowed inlining you would still need to allow linking because no one has found the one true hierarchy to rule them all."""

Now would you classify your quotation as "rhetorical flourish" or "more heat than light"? Personally, I call it "disappointing".

@Mr Champion. Many of us in Internet space no longer trust MS. They (MS) are now plodders and are fast-becoming IP luddites. Like many others I hope Google lays a big glove on you. And well I am at it, please do something useful with IE 7 going forth. Please for god's sake make it behave like a true citizen of the internet - as an equal, not as a non-compliment bully. I am sick and tired of designing web pages that need special hacks for IE to render them properly. Hopefully Safari on Windows will force you to wake up! I agree with Tim's position. color me cynical when it comes to the underlying intentions of MS.

Sun recently open sourced lots of software in a strategic business move.

Google uses lots of open source software, and contributes some, in a strategic business move.

Microsoft thinks software is business and .

I'm mostly a leftist. Richard Stallman is my hero. GPL is god's gift to humankind. But a spade is a spade, and at least Microsoft is the most honest player in the room when it comes to this issue. (Yes, I really just said that. ;-)

That said, people for whom blogging is most likely in their job description with a multi-billion dollar technology company should slow down before slamming Dare too hard

I would generally tend to agree, but there are notable exceptions. DNS for instance jumps to my mind: it does not fit a network of peers, is unsafe by design, the implementations are usually broken, the bulk of DNS traffic is redundant, etc.

The Internet is not a magical place but a human artefact which cannot escape our motivations and fears.

DARPA booted the Internet and the generals naturally wanted a hierarchical name resolution system in order to keep *command and control* (or, rather, the illusion of it). Businesses liked DNS because one could *own* site names although it does not guarantee safe resolution. And users - who don't understand how it all works - can't possibly figure out how DNS leads to man-in-the-middle attacks on TLS/SSL connections, nor why DNS makes mail spam possible.

I'm not going to enter into the whole "is APP a general purpose editing protocol for the web" discussion because that's a highly abstract debate; I'm personally leery of anyone who tells me that one tool/strategy/approach is the magic solution for all problems.

But what I can offer up is the concrete evidence that we've been using APP as the foundation of the Google data API model for well over a year now and it's standing up quite well in a wide variety of services (blogging, photo collections, spreadsheets, web app provisioning, video [soon], ...) and it's being used today by a wide variety of clients (server-side web apps, desktop apps, javascript clients, mobile, ...).

So while APP isn't a magic bullet that solves all web content editing problems, its foundational role in GData makes it pretty clear that it is applicable to a wide variety of them. I'm hoping that this fact doesn't get lost in all the arguments flying in both directions. Can the GData implementation of APP be made better? Certainly. Would APP benefit from some additional extensions that help to broaden its utility. Certainly. But from where I sit, it's a great foundation and there's no reason to discard it and start over in the contexts where it is applicable.