A more low-tech approach to ping hubs 

When talking with the Google guys earlier today I told them that there was an even more low-tech approach than the <cloud> element for the kind of notification they were doing. As I was reading their spec, I decided to look into it to refresh my memory. I'm writing it up here, so everyone can compare.

1. Unlike <cloud> this protocol was very widely implemented. Support for this protocol is already baked into almost all blogging software, and (likely) many CMSes.

2. The feed indicates which hub it belongs to using a <category> element. You can see an example looking in the feed for my Radio weblog. I've made a copy of that feed in case the link goes bad (I hear that Radio weblog hosting may end in December.)

This means that if you want to find out if this feed changed, you should monitor the indicated changes.xml file.

3. When the feed updates, it pings the server that maintains that changes.xml file. The coupling here is much looser than the coupling that Google is using. But the changes.xml file can be read once a minute. If your application can handle up-to-the-minute updates instead of up-to-the-second, then this approach works fine.

A neat conference hack? 

Hey I just had an idea for a conference hack you can do at a traditional audience-oriented conference.

I have a theory that you could grab any random person from the audience and put them on stage and they'd give a better talk than the usual conference speaker because they wouldn't have had time to prepare slides or get nervous and plan a speech in their head.

So, why not do exactly that!

Have a "surprise panel" mid-afternoon on the first day, around 3PM. The conference moderator takes the podium and says: "Would the following people please come up on stage." And then he'd name four people chosen at random from the audience. Then they'd have a discussion about the previous panels and speeches, the topics of the day in whatever industry or profession the conference is about.

The only problem with this idea is that by 3PM most of the people would already be out in the hallway schmoozing because the speeches and panels were so boring. Not exactly sure what to do about that.

Google's Pubsubhubbub 

It's got a weird name, and I found the spec somewhat hard to understand.

But thanks to Brad Fitzpatrick and Brett Slatkin from the team at Google that implemented it, I now understand what Pubsubhubbub does.

It allows you to receive updates of RSS feeds without polling.

It makes it possible to build a distributed Twitter-like system with components that are not made by a single company, and with servers not run by a single company.

It makes instant updates possible for RSS.

It makes it possible to build a Twitter without the limitations of Twitter. (For example, no 140-character limit, the ability to handle enclosures, categories without #hashtags.)

The protocol it defines seems reasonable (I'll have to implement one side of it to be sure) and because it has the backing of Google, one of a very small number of companies with the resources to make something like this work, it has a chance of gaining traction and when it does, scaling.

In fact, it's part of one of the components I asked Google to implement in a blog post here on May 28, as Brett pointed out in our phone conversation earlier today. It's nice to see that at least a few people at Google see the possibility of assembling a Twitter-like notification system with the Small Pieces, Loosely Joined approach.

Drilling in one more level, here's how it flows.

1. Any feed that wants to participate in this network must add a bit to the feed that indicates which ping server is handling notifications on its behalf. There can be more than one.

2. When a subscribing application initially parses the feed and notices this bit, it sends a notification to each server saying "I want to be notified when this feed updates."

3. When the feed updates, it pings each of the servers it has registered with saying "I have updated."

4. The server then pings each of the subscribers saying "He updated."

The subscriber must have a known address, therefore must not be behind a firewall or NAT. For client apps, they need some kind of proxy that has a known address. This limit is signficant, but certainly not insurmountable.

I would like to see them understand RSS syntax in addition to Atom syntax, and I understand from the spec that that is forthcoming.

Update: http://superfeedr.com/ has also implemented this protocol.

Imho, the OPML Editor is not hard 

I've heard people say, here and there, that the OPML Editor is too hard to use, or overkill for certain projects, but honestly -- I don't think it is. I think there may be other problems, and confusion about what it does, because it surely does a lot. But for a specific task, it's not really that hard to set up and use. If it is, I want to work on making it easier.

Let's start with an application that a fair number of people have, that the OPML Editor has a solution for -- backing up your tweets, and those of the people you follow. As Apple likes to say about the iPhone, "There's an app for that."

http://editor.opml.org/twitterCalendarTool.html

The docs on that page explain how to install the tool.

Installing it is much like installing an Adobe Air application. First you have to install the runtime, I don't think there's anything complicated about that, then install the tool, which requires a little setup, but again it's not complicated. If you were to install an app in .Net or Java it would work the same way.

Then, once you have the runtime installed, installing new tools is even easier. There's a list of tools that are available, it's called the Tool Catalog. There's a menu item in the OPML Editor app that opens the catalog. Next to each tool there's an Install link. If you click on it, guess what, it installs the app. A confirmation dialog appears, making sure that's what you want to do. And if the app requires you to set some prefs, a page where you enter those prefs appears.

Now I'm working to make it easier. And if people hit walls installing this stuff, I want to fix them. There are still some things I can't do. I can't build the OPML Editor kernel on Macintosh, and this may present a problem down the road, but for right now everything is cool. And if more people use it, it'll be easier to get the build process streamlined. It's all chicken and egg.

So when you use the OPML Editor you help make it better and make it easier for me to develop more tools, which I am working on, all the time.

Bad Hair Day #3 

Marshall is buying a new house, so I recruited two guests for this podcast, and they were excellent.

They had really bad hair!

Michael Gartenberg is a Interpret analyst, an expert on mobile devices.

Andrew Baron is a video producer and entrepreneur, founder of Rocketboom and the brand new video aggregator, Mag.ma. At the end of the show he gives out beta access codes for the new service.

We talk about Google's Chrome OS, iPhones, video, realtime stuff and of course Andrew's Mag.ma service.

The feed: http://badhair.us/rss.xml