This is about Atom, weblogging systems, and loosely coupled systems, but first, why I like RSS, and use it now:
- It's supported by everything
- It's really really simple
When I use RSS, I use RSS 0.91. It's my guarantee that the feed isn't going go any further, and - so long as you can see it - you're not missing anything. What you see is what you get. I haven't seen anything that competes with RSS 0.91 for simplicity, or in its niche.
But RSS 0.91 is an output format, it's not an abstraction layer.
Why I like Atom:
Atom is an abstraction layer. I like Atom because, of all the weblogging systems I've seen, and most of the news systems too, it demands the minimal set of metadata you need to do useful operations.
Demands: Because Atom demands last-modified as well as a created date, that metadata has to exists. A pita the first time I encountered it, sure, just like the post title (which still annoys me). But what Atom says is: If you want to play the weblog game, this is the metadata you need. That, and some other stuff (it's all in the Atom spec).
What Atom is is the shape of the post. Just like email. Email isn't IMAP, or POP, or procmail, or Outlook, or SMTP, or Mail::Box, or mbox or Maildir, or any of the things that consume, produce, store or route email. It's RFC 2822, and email, for all its faults, has been enabled by saying: Headers look Like: This, you gotta have certain headers, and this is what a date is.
This is the way the world works. When it comes to chairs, there isn't some authoritative chair, and all chairs are like that chair, and some arse to sit on it, all arse instances being somehow like that arse. No. There's the act of sitting. There are things which are chair-like (which afford sitting upon) and things which are arse-like (which afford sitting with).
What Atom says is: If you want to afford these behaviours, then you have to be weblog-like in this respect and editor-like in this respect, and it doesn't matter what else you do, but those are the shapes we require.
And because Atom demands this certain minimum set of data, which has been decided by experience and thought, you can use [will be able to use] any editor, any weblog system that accepts posts, any templating system. What I'm describing here is the loosely coupled architecture, and what the benefit is, is evolvability.
We've had a lack of innovation in the weblog space because there aren't decent abstraction layers. You can inject posts, that's it, but bound together are: the datastore, templating, display, editing, permissions, commenting and so on. Occassionally there's some innovation -- there was a website that sold Blogger templates for a while, I believe, and MovableType plugins extend the templating and display systems wonderfully. But the applications themselves are still monolithic.
Atom says: Given everything else is in flux, here's our one fixed point. The post. The metadata of the post. The relationships between posts. That's it.
Out of that single abstraction everything else can crystalise.
I can see a templating system spin out. The templating system for my weblog is a few lines of Python (calling libxslt) and some XSLT files for transformations. It needn't be -- Movable Type's biggest asset (in my opinion) is the community and plugins surrounding its templating system. I'd like to be able to drop that in instead. One day I hope I'll be able to.
The editing system will also spin out. But whereas currently it's a little hackish - the weblog editing tools are crippled by what the API offers - the Atom specification has been designed to allow fully functional editing tools. I'd like the functionality and simplicity of the old Blogger interface using the Atom API to post to my weblog. And sometimes I'd like to be able to post to it using a desktop app. And have a custom weblog search tool running on my desktop that's indexed my weblog (using the relationships in the posts and the Atom API) to assist me.
One day I hope I'll be able to.
Here's how I see a future weblogging system:
- A datastore that holds the posts, possibly the file system
- A templating system. Probably a cgi script that does XML transforms (so I can trade templates with people, because we all know we're operating on collections of Atom documents), or a Movable Type-like templating tool. Optionally a cache.
- An inject script that implements the Atom API, allowing different tools to create, edit and manage posts
- Off-the-shelf editing tools, aggregators, indexers and so on.
- Drop-in tools that can be consumed by the templating system that produce side-bars, commenting and so on.
- Maybe a standalone publisher that uses the templating system to generate static files and SFTP them to a remote location.
After the Atom API, a specification to do comments and another to do templating should probably be next. (The Atom API is a really big deal because it allows evolvability in a space where we already know there's demand. It's fairly easy to implement too, see the Atom API for a good case study. I do think templating will come next.)
There are tools we can't think of yet, which may build on the routing, or the linking, or any other corners of the Atom shape we haven't really exploited yet. (The Atom Entry is standalone in a way the RSS Item isn't.)
It'll be good, to see the end of monolithic weblog tools, and evolvability in its place. This is what I think Atom allows.
(I'm making a big assumption here, that design decisions and understanding the problem space are a bigger block to people getting involved than the ability to write code. Atom encodes an understanding of the problem so that people can make interoperable tools that concentrate on features, instead of thinking about which particular bits of metadata should be kept, and how to structure posts.)
A weblogging system made out of a bunch of parts like this sounds really technical and hard to install, but it shouldn't be. Free software should allow bundles to be made so installing is just a matter of making a couple of directories and dropping in some cgi scripts, as it is at the moment. But changing the templating system should be a matter of just pointing it at the same datastore. And an editing component that looks after user management should be drop-in and replaceable, in much the same way as you can switch between different webmail applications if you install them on a server to look at an IMAP mail store. (I guess what I'm talking about is the benefits of commoditisation. If you buy Joel on Software's argument that successful products have commoditised their complements (the other products and services you need to make use of them) then desktop weblog editing tools (ecto, basically) need to commoditise weblog publishing engines, and front-ends need to commoditise back-ends -- which is what Blogger did (accidentally) by publishing with FTP to begin with.)
A little more on RSS:
What RSS 1.0 has is machine-readability. Its problem wasn't complexity, but complexity without purpose. It hadn't been tested against the requirements of tools.
What RSS 2.0 has is no guarantees. It can't act as a fixed point (in my opinion). It's simple enough for publishing but given namespaces and the amount of optional elements, I can't be sure that if a tool supports the minimum spec I have everything I need to move between many different tools. It's as if RSS 2.0 is defined not by the spec, but by what tools that consume RSS 2.0 do with it -- much the same difficulty as Microsoft Word documents. Word docs are whatever Word chooses to see, regardless of what OpenOffice or other consumers do with them.
So I think RSS 2.0 will become just an output format, like a print stylesheet. It's not recombinant enough. But for me, RSS 0.91 already occupies that space.
Whereas with Atom, everything is tightly defined. Like email, I'd feel confident opening my post in lots of different tools and knowing it's just different views of the same thing. With RSS 2.0 I can't quite tell.
(And on the politics of the situation: My preference is for particular landscapes rather than technologies. I like the landscape that Atom would enable+encourage, but that's not to say RSS couldn't do the same, if it wants to. I'm not sure it does want to, it's already extremely well optimised for the landscape it wants (it's enormously popular and really well supported, no more evidence needed), a different one. So I'm not interested in politics, it's horses for courses. When Atom's finalised, I've still got applications I'll be making new RSS feeds for.)
This is about Atom, weblogging systems, and loosely coupled systems, but first, why I like RSS, and use it now:
When I use RSS, I use RSS 0.91. It's my guarantee that the feed isn't going go any further, and - so long as you can see it - you're not missing anything. What you see is what you get. I haven't seen anything that competes with RSS 0.91 for simplicity, or in its niche.
But RSS 0.91 is an output format, it's not an abstraction layer.
Why I like Atom:
Atom is an abstraction layer. I like Atom because, of all the weblogging systems I've seen, and most of the news systems too, it demands the minimal set of metadata you need to do useful operations.
Demands: Because Atom demands last-modified as well as a created date, that metadata has to exists. A pita the first time I encountered it, sure, just like the post title (which still annoys me). But what Atom says is: If you want to play the weblog game, this is the metadata you need. That, and some other stuff (it's all in the Atom spec).
What Atom is is the shape of the post. Just like email. Email isn't IMAP, or POP, or procmail, or Outlook, or SMTP, or Mail::Box, or mbox or Maildir, or any of the things that consume, produce, store or route email. It's RFC 2822, and email, for all its faults, has been enabled by saying: Headers look Like: This, you gotta have certain headers, and this is what a date is.
This is the way the world works. When it comes to chairs, there isn't some authoritative chair, and all chairs are like that chair, and some arse to sit on it, all arse instances being somehow like that arse. No. There's the act of sitting. There are things which are chair-like (which afford sitting upon) and things which are arse-like (which afford sitting with).
What Atom says is: If you want to afford these behaviours, then you have to be weblog-like in this respect and editor-like in this respect, and it doesn't matter what else you do, but those are the shapes we require.
And because Atom demands this certain minimum set of data, which has been decided by experience and thought, you can use [will be able to use] any editor, any weblog system that accepts posts, any templating system. What I'm describing here is the loosely coupled architecture, and what the benefit is, is evolvability.
We've had a lack of innovation in the weblog space because there aren't decent abstraction layers. You can inject posts, that's it, but bound together are: the datastore, templating, display, editing, permissions, commenting and so on. Occassionally there's some innovation -- there was a website that sold Blogger templates for a while, I believe, and MovableType plugins extend the templating and display systems wonderfully. But the applications themselves are still monolithic.
Atom says: Given everything else is in flux, here's our one fixed point. The post. The metadata of the post. The relationships between posts. That's it.
Out of that single abstraction everything else can crystalise.
I can see a templating system spin out. The templating system for my weblog is a few lines of Python (calling libxslt) and some XSLT files for transformations. It needn't be -- Movable Type's biggest asset (in my opinion) is the community and plugins surrounding its templating system. I'd like to be able to drop that in instead. One day I hope I'll be able to.
The editing system will also spin out. But whereas currently it's a little hackish - the weblog editing tools are crippled by what the API offers - the Atom specification has been designed to allow fully functional editing tools. I'd like the functionality and simplicity of the old Blogger interface using the Atom API to post to my weblog. And sometimes I'd like to be able to post to it using a desktop app. And have a custom weblog search tool running on my desktop that's indexed my weblog (using the relationships in the posts and the Atom API) to assist me.
One day I hope I'll be able to.
Here's how I see a future weblogging system:
After the Atom API, a specification to do comments and another to do templating should probably be next. (The Atom API is a really big deal because it allows evolvability in a space where we already know there's demand. It's fairly easy to implement too, see the Atom API for a good case study. I do think templating will come next.)
There are tools we can't think of yet, which may build on the routing, or the linking, or any other corners of the Atom shape we haven't really exploited yet. (The Atom Entry is standalone in a way the RSS Item isn't.)
It'll be good, to see the end of monolithic weblog tools, and evolvability in its place. This is what I think Atom allows.
(I'm making a big assumption here, that design decisions and understanding the problem space are a bigger block to people getting involved than the ability to write code. Atom encodes an understanding of the problem so that people can make interoperable tools that concentrate on features, instead of thinking about which particular bits of metadata should be kept, and how to structure posts.)
A weblogging system made out of a bunch of parts like this sounds really technical and hard to install, but it shouldn't be. Free software should allow bundles to be made so installing is just a matter of making a couple of directories and dropping in some cgi scripts, as it is at the moment. But changing the templating system should be a matter of just pointing it at the same datastore. And an editing component that looks after user management should be drop-in and replaceable, in much the same way as you can switch between different webmail applications if you install them on a server to look at an IMAP mail store. (I guess what I'm talking about is the benefits of commoditisation. If you buy Joel on Software's argument that successful products have commoditised their complements (the other products and services you need to make use of them) then desktop weblog editing tools (ecto, basically) need to commoditise weblog publishing engines, and front-ends need to commoditise back-ends -- which is what Blogger did (accidentally) by publishing with FTP to begin with.)
A little more on RSS:
What RSS 1.0 has is machine-readability. Its problem wasn't complexity, but complexity without purpose. It hadn't been tested against the requirements of tools.
What RSS 2.0 has is no guarantees. It can't act as a fixed point (in my opinion). It's simple enough for publishing but given namespaces and the amount of optional elements, I can't be sure that if a tool supports the minimum spec I have everything I need to move between many different tools. It's as if RSS 2.0 is defined not by the spec, but by what tools that consume RSS 2.0 do with it -- much the same difficulty as Microsoft Word documents. Word docs are whatever Word chooses to see, regardless of what OpenOffice or other consumers do with them.
So I think RSS 2.0 will become just an output format, like a print stylesheet. It's not recombinant enough. But for me, RSS 0.91 already occupies that space.
Whereas with Atom, everything is tightly defined. Like email, I'd feel confident opening my post in lots of different tools and knowing it's just different views of the same thing. With RSS 2.0 I can't quite tell.
(And on the politics of the situation: My preference is for particular landscapes rather than technologies. I like the landscape that Atom would enable+encourage, but that's not to say RSS couldn't do the same, if it wants to. I'm not sure it does want to, it's already extremely well optimised for the landscape it wants (it's enormously popular and really well supported, no more evidence needed), a different one. So I'm not interested in politics, it's horses for courses. When Atom's finalised, I've still got applications I'll be making new RSS feeds for.)