graemef.com

I’ve been having a think about Steve Maine’s SubscriberTrack proposal. It’s a great idea. When visitors are few and far between (no! don’t go yet!) there is an irresistible urge to discover more about who that other person in your server logs (you know, the one who isn’t you) is. Unfortunately I can see a problem with the initial proposal; although I don’t doubt you could get some useful information from it, in practice it wouldn’t work quite as well as hoped.

The problem lies in the assumption that, after a “subscribe” notification, the subscriber keeps reading until they explicitly “unsubscribe”. This ain’t gonna happen for a thousand reasons - somebody uses a new aggregator (leaving their old aggregator subscribed and forgotten about), somebody else reformats their hard drive, somebody else gets run over by a bus… you know the kind of thing.

This means you wouldn’t really be able to keep a list of subscribers (which I assume is the intent), because it would quickly get out of sync with reality. Knowing that, the only information you’d look at would be the new subscriptions. The unsubscribe notifications would be pretty much worthless. I guess the only real use would be to inform you that you’d suddenly said something that made everyone unsubscribe at once, but you could probably get the gist of that from your server logs anyway J

There’s another problem with subscribe/unsubscribe – it doesn’t fit with the way all aggregators work. Some aggregators (e.g. SharpReader) allow a feed to be opened much like a web page. There’s no subscription involved, yet the RSS feed gets a hit and the person on the other end is most likely having a look through the content, perhaps wondering whether or not to subscribe. These people are worth considering.

Other aggregators (e.g. PopHeadlines) have no notion of subscription at all. It’s another application’s job to manage subscriptions, and that other application doesn’t necessarily know about RSS (let alone SubscriberTrack) at all. The initial SubscriberTrack proposal suits the majority of today’s aggregators, but there’s still a lot of room for innovation at the client end. The traditional 3-paned aggregator may be replaced one day.

To get the best, most useful information from those hits to your feed, the server would ideally be able to log who’s reading with every hit. That way you’d not only know who was reading your feed, but how often they check it for updates, when they last checked it, and so on. Given this, I spent a short while trying to interpret RFC 2616 section 14 in a way that meant it would be OK to put the URI of a blog (or something else) in the HTTP Referer header. I think I failed, but I may not have been trying hard enough. If the information we’re talking about could be squeezed in there somewhere without offending anyone we’d have the best possible solution. Even folks serving up feeds from plain old files without any server side code would benefit. No XMLRPC endpoint would be required; the information would show up in the regular server logs.

If it can’t go in the HTTP headers, then that leaves two useful options. Firstly, the SubscriberTrack call could be made alongside every request for the feed. I’m not an expert on XMLRPC, but I’m guessing that the extra traffic this would generate would be a bad thing

The second option is a compromise between the one-time and every-time calls. Ditch the “unsubscribe” notification, and put a TTL on the “subscribe”. There’s your up-to-date list of subscribers, and you’d know roughly how frequently they fetch your feed…