Stupidfool.org

The Folly of the Ping

I have to admit: I really don't understand the pinging hysteria. Everyone wants to be pinged, and I really wonder if everyone thinks that's the best we (as an industry) can do.

Don't get me wrong--our tools have pinged weblogs.com and blo.gs for years. But of late, there are more and more parties interested in receiving direct pings, rather than federating based off of the updates that weblogs.com and blo.gs have always propagated. [1]

And frankly, it just makes it wonder: it's a bit ridiculous to suggest that direct pinging is the only possible technical way to find out about updates to a site. Google and other search engines seem to do pretty well in keeping their indexes current, even though they don't receive any pings. And they're indexing billions of web sites, while there are only tens of millions of weblogs.

So when our tools all ping weblogs.com and blo.gs, why is it so crazy to assume that an update on a TypePad weblog, for example, would propagate as a ping around all interested listeners within 5 minutes? Or even 5 hours?

I had high hopes for FeedMesh, because I believed that ping federation would solve at least some of the problems that we see. But alas, I don't really see that effort going anywhere. [2]

So we decided to do something about it. For services like TypePad and LiveJournal, the issue of authentication & spam pings is not as problematic--if you connect directly to us, we can provide a stream of updates to blogs on our services that listeners can watch.

And starting today, that's what we plan to do. Read Brad's post to find out the technical details, but basically, you'll be able to make an HTTP request to http://updates.sixapart.com/atom-stream.xml, and have Atom updates from LiveJournal and TypePad streamed directly to your client. [3]

And if you're interested in consuming the stream, take a look at Tatsuhiko's post about his new XML::Atom::Stream module, which provides an event-based wrapper around the stream and integrates easily with XML::Atom.

In order to solve the real issue of spam blogs--particularly the huge number that are being produced by the same weblogging tools that you or I use--I believe we'll need to think about reputation built upon identity systems like OpenID. But in the meantime, we're happy to provide a valid source of pings from millions of weblogs powered by our tools, and we'll see where it goes from here.

[1] Yes, obviously, those updates are not without issues. Weblogs.com pings often time out, and requesting their changes.xml may not be that much more reliable.

[2] I even developed a CPAN module for receiving FeedMesh pings, back before I knew it was FeedMesh. Which is why it's called POE::Component::BlogCloud instead of Poe::Component::FeedMesh. But of course, I don't actually know if that cloud really was the FeedMesh, which may be the least-documented protocol ever. Yes, I realize I'm not really making a good case for FeedMesh.

[3] TypePad updates will start to be added to the stream tomorrow.

I use "Loudsp." daily. Really.

I was just watching Cellular, and considering that they even make a sort-of-joke out of this:

Why is it so fucking difficult to mute a Nokia phone while on a call?

My First Plugin

Well, not really... but my first Movable Type plugin in a while.

I've been looking at the Movable Type 3.2 beta quite a bit from the outside in--i.e., by using the web application--but I wanted to explore the new options in the API. So (with Anil's prompting) I decided to write a plugin for 3.2 that would allow transferring posts--with all of their comments and TrackBacks--from one weblog to another.

There may be existing plugins that already enable this, but I wanted to take advantage of the new action pulldowns in the List Entries screens (both per-weblog and the global overview).

As an aside, what's amazing to me--and probably to everyone else who remembers the first release of Movable Type plugins--is how much plugin functionality has evolved over the years, and how well integrated into the UI plugins have become, particularly in 3.2. The first plugin-enabled release, Movable Type 2.2, allowed plugins to add new template tags, not touching the UI at all; Movable Type 2.6 allowed plugins to add new text formatting filters; Movable Type 3.0 and 3.1 allowed plugins to build applications that looked like Movable Type, but looking back, they always felt like separate applications.

With Movable Type 3.2, the plugin interfaces have evolved to the point where plugins are completely transparent: there doesn't have to be a difference in look-and-feel between plugins and core functionality. The two key areas of evolution are the listing screens and the plugin management and per-weblog configuration settings. This is great.

Getting back to my plugin, then, I used the new APIs for adding hooks to the listing screens to enable the following flow:

1. Go to List Entries (either in a specific weblog or in the System Overview).
2. Select the entries you'd like to transfer.
3. Select "Transfer Entries" from the "More actions..." pulldown menu.
4. Select the weblog to which you'd like to transfer the entries.
5. That's it!

If you have Movable Type 3.2 (you'll need a recent version of the beta), you can try out the plugin:

• Transfer 1.0
• The source code, if you just want to look at that

Update: a new ProNet post shows the plugin in action, along with describing the plugin functionality in more detail.

Open Data

Cory writes about the rumors of the new Intel Macs using Intel's Trusted Computing hardware:

It means that the price of being a Mac user will be eternal vigilance: you'll need to know that your apps not only write to exportable formats, but that they also allow those exported files to be read by competing apps.

Exactly. In some sense, open data is more important than open source. Your data is more valuable than the tools you use--you can always find new tools, but if you lose access to your data, no tool in the world will give you access to it.

It's similar to what we've always called our Philosophy of Yes at Six Apart:

The "export" button in Six Apart's products keeps us on our toes. Knowing that you can leave at any time is our motivator to keep on developing stable, intuitive and flexible applications. We want you to stay because you like the product, not because you can't get out.

For me, it's always been easier to trust a tool that allows me to get my data out if I watch to switch tools.

And so, since day one, Movable Type and TypePad have had the ability to Export your posts--not because we wanted people to leave, but because we wanted people to stay.

Design Patterns & Data::ObjectDriver

It's sad to see that the Class::DBI mailing list and wiki have closed down, for a number of reasons...

For one thing, I can feel for Tony--it's always hard to have a project that you're working on (out of your own time, for a job, or whatever) criticized, and to have customers--whether they're developers or end users--not happy with your decisions or the pace of your releases. That said, I don't know enough about the situation to say much more than it looks to have gotten out of control much more quickly than it should have.

But from another angle, the discussion about design patterns is really interesting to me (and, I gather, to a lot of people on the cdbi list).

It's a really fascinating problem, designing an extensible object-relational mapper (and a common one for people on CPAN). We've had a good, working mapper in Movable Type and TypePad since the first release of Movable Type (the venerable ObjectDriver code), which works with Berkeley DB, MySQL, PostgreSQL, SQLite, and a number of other databases that people have hacked it to work with.

Over the past couple of months, we've been revisiting our ObjectDriver code with the idea of keeping (mostly) the same calling structure, but adding layers for caching and database partitioning, and releasing the entire mess to CPAN as a module called Data::ObjectDriver. (Brad wrote about this, as well.)

The idea is to make application development simple; if that makes creation of new database-backed objects a little more difficult, then so be it. For example, with partitioning, we're not attempting to go the DB2 route of saying "anything can be partitioned in any which way, and we'll handle it all!"--frankly, while I honestly think that database partitioning is a feature any database platform should have, it's a hard problem, and is pretty application-specific. So what we're doing is preventing a mental model for doing partitioning: figure out what objects you want to use to partition your data on, and we'll do the mechanical work of automatically connecting to the right database and performing all operations there.

But the applicable part here is that we've talked a lot about getting the design pattern first for all of the drivers. In particular, we're converting TypePad to use the new Data::ObjectDriver, but we have a couple of extensions we want to make to it. We've talked through multiple inheritance, delegation, mixins, etc. Eventually we settled on using delegation, with a DBI-like system of a core Data::ObjectDriver::Driver::DBI class, which provides the main driver functionality, and Data::ObjectDriver::Driver::DBD subclasses for specific database platforms (MySQL, PostgreSQL, etc).

In addition, I've long thought that one of the main problems with Class::DBI is the fact that it's two things in one class: it's simultaneously the base class for all database-backed objects, and the class with all of the mechanical code to generate SQL statements.

Some of the design decisions that have always been in the ObjectDriver code--the separation of the core into a BaseObject and Drivers, which are 2 separate classes--will help to solve some of the Class::DBI problems. That's not to say that we won't replace those with other problems, of course. :)

Why don't you just...

The weirdest thing about the Orkut newsletter that Jeremy Zawodny received is the closing:

stay beautiful, orkut.com team

"stay beautiful"? Is this a Manic Street Preachers mailing list?