Why subscribe??

If you've read my profile, you know I work with mainframes. In most cases (and in this one), it means the person involved has a lot of years under their belt. I happen to have worn many hats during that time period, one of which was supporting communications.

That experience leads me to question the current model of "subscribing" to things like calendars and RSS feeds. It's not subscribing in the e-mail / mailing-list sense, at all. Instead, it's what we used to call "polling". In polling, one device wakes up every so often, and sends a signal to the other to say "do you have something for me?". If the other end has something, it sends it, otherwise it replies basically "no, try later". The former is called productive polling, and the latter of course is non-productive polling. Non-productive polling is bad, because it uses network bandwidth to little effect. The trick, however, is to get the polling frequency "right" - too slow, and response time of the application is bad; too fast and you just increase the proportion of polling which is non-productive.

Non-productive polling is already happening with RSS feeds, with people setting their aggregators to check their favorite feeds too often. The underlying protocol is basically an HTTP version of "has there been an update?" (do you have anything for me?) and "not yet" (no, try later). It is multiplied by the fact that sometimes there are thousands of these aggregators asking per hour. There are also aggregators which are poorly implemented and which retrieve the latest feed over and over again even if it has NOT been implemented - which means they ignore the "efficiency" of "no, try later" and retrieve the entire piece of data again, over and over. One site owner, Glenn Fleishman, even studied some of these effects and wrote some code to deal with them that helped, but of course it didn't eliminate the source of the issue.

Calendar subscriptions, I fear, may in fact have the same problem, as people's calendaring tools keep checking to see if their favorite calendars have been updated. Given some people's desire to constantly be "up-to-date" they may set their tools to check even more frequently than they check RSS feeds, driving up the proportion of non-productive "polling".

Contrast this with a mailing list subscription. A mailing list uses bandwidth only when there's information to send. It of course requires a central mailing list service, which retains the addresses of the subscribers. There is some "polling" involved - your e-mail client checks regularly to see if "You've got mail!" which is a polling activity- but I don't think people generally set it to run so frequently.

Maybe we could combine the two to improve efficiency: when you subscribe to an RSS feed or calendar, it would send via e-mail some XML representing the new information, in a MIME segment with the proper Content-type, and e-mail clients would pass this to the local (desktop) aggregator or calendar client. This would work well in calendaring tools that already layer on top of e-mail, such as Notes and Outlook, wouldn't it?