ContentDarren Chamberlain writes:
I was going to post this as a comment to the Blogging In Flock post, but I see you’ve closed comments on that post. It looks like Elias Torres has implemented an APP server for WordPress. I haven’t tried it, but it looks interesting, and Elias usually makes good stuff.
Thanks for pointing that out, Darren. I had noticed that as well and look forward to seeing if it works.
The real trick will be getting Atom Publishing Protocol support merged into the main WordPress tree. With stuff like this it is all about priorities, and as evidenced by the difficultly in getting valid Atom 1.0 support in the WordPress mainline, (note that my migration back to stock WordPress broke my patched Atom 1.0 feed), it is a matter of whether or not the right people find it important.
Fortunately, the momentum is strong for APP. Google’s GData API uses an exchange protocol based on APP. And yesterday’s launch of a Google Base API layers another incredibly powerful application on the protocol. Blogger.com is moving exclusively to APP (and I just noticed Google also recently released a GData API for Blogger). That move is prompting Windows Live Writer to support APP in the near future as well.
Speaking of Windows Live Writer, and by association, Windows Live Spaces, I think people need to step down from the rhetoric around what constitutes a “blog.” In my opinion, Writer and Spaces are the most obvious signs that these technologies are now part of the mainstream. You could certainly make a case that there are more hard-core publishing tools designed for the hard-core publisher, but slow down for a second and get some perspective. The 99% case of normal human beings are never going to be “hard-core” about personal publishing. They don’t need or want the tools that you and I do.
Besides, I love that Microsoft is getting so deep into the personal publishing game at all. Think about it; the world’s #1 consumer software developer, a company with by far the most “touch” in the technology world, is now bringing technologies that we know and love to a much broader audience. Will they always do it in a way that meshes exactly with what I personally need? Of course they’re not going to, and they shouldn’t be targeting me as a consumer. Will I try and influence that direction? Hell yeah, but I won’t mistake my own personal requirements for that of the majority.
And if you’re reading this post, then you too are in the miniscule minority in terms of target demographics.
August 24th, 2006 at 12:09 pm
I think people need to step down from the rhetoric around what constitutes a “blog.”
I think it’s a self-correcting problem… keep shouting loudly enough about something that you’re wrong about, and people will eventually stop listening, right? Crying wolf, and all that?
September 21st, 2006 at 2:15 pm
But GData– yes, APP based– tauts on their webpage things like Queries, Optimistic concurrency (versioning), and Authentication over APP. But are the differences enough to go for yet another named protocol?
For queries: Yes, it isn’t specifically defined in APP, but the use of the popular OpenSearch 1.1 would fix that. Extensions to APP, just as good. But Google makes use of their own search extension (hybrid/broken OpenSearch)… Now I have to “one off” for google services.
For Optimistic concurrency: This isn’t a feature of the GData Protocol, it’s a feature of Google’s implementations! The Member URI is still obtained from the edit rel link. And this URI is still considered opaque by the client. This is an Atom feature, and it is trivial for various implementations to turn it into a unique URI for versioning. Google uses incremental (1,2,3) numbers, but it could very well be a URI based on a UUID without even using a semanticly meaningful slugname. Not enough to say that it’s a change in the protocol, imho.
A standard authentication scheme is lacking in Atom. But I think it’s good that Atom punts it. The Atom Publishing Protocol, itself, is about reading and editing resources… all designed to be orthogonal to the authentication problem. APP suggests that one SHOULD authenticate, but doesn’t describe how… and shouldn’t. There a dozens of authentication and security methods (e.g.- public key, http basic & digest, ssl, etc). Let the service decide how it’s to be done, and these methods all are separate enough that they won’t intrude into the core editing flow.
Side note: GData lacks introspection documents, which I think they need to fix.
Why can’t Google just say “Use APP and OpenSearch along with our Google Authentication system”? It’s all laid out there for them.
BTW, GData lacks the use of APP’s introspection documents.
But seeing that they haven’t, and probably won’t… I would consider it to be an “It’s Almost an APP world, after all.”
All there, spreading confusion in the minds of new developers.