More on how to move beyond polling for information distribution

In response to some reader comments, I'd like to elaborate a little on my thoughts for how to move beyond polling. I'm still not prepared to offer my full model for an information distribution architecture, but a few comments are in order. What follows is my response to the reader...

I actually didn't mention any specific interrupt method, and in fact I clearly noted that the internet has a host of problems that would need their own solutions. I neglected to mention spam, but it certainly is in the "etc." that I mentioned.

To be clear, interrupts are NOT analogous to email. After all, email reception is a POLLED transport mechanism. I would also note that email itself is a good candidate for my approach to information distribution.

Spam wouldn't be a problem with the kind of approaches that I can envision. Of course, spam is always in the eye of the beholder.

The main reason spam wouldn't be an issue is that any TRUE information distribution architecture would have a wide range of controls so that random idiots couldn't simply spoof real people. There are lots of techniques to address these issues that real people are already using.

It's kind of silly to say that "Polling an RSS feed allows us to 'turn off' the channel ourselves", since a true information distribution architecture would certainly allow you to do exactly that, and to do it in a way that doesn't have the negative consequences of polling. Polling is a particularly bad choice for turning off an information channel. It's far better to directly inform your channel connection of your intentions. "Off" is only one choice. A wide range of filtering options, including delivery at specified times of your choice, would be far better.

You said that "we don't even get the chance to 'opt in' for unsolicited email", but I think there is software that does do precisely that. I've sent unsolicited email to a few people and then had to go through a verification negotiation mechanism before my mail would be let through. It wasn't a big burden on me and it was a big benefit for them. The point should be that we all should have those options without having to acquire, install, configure, and manage our own mail server software. In any case, this isn't an argument against a non-polled information distribution mechanism.

You wrote "polling isn't efficient, but it's a great alternative to being interrupted by anyone with a computer", but that isn't even true. As you've noted, spam and other email abuses are a real problem, but email itself is based on polling (timed polling unless you turn the timing feature off).

Although I haven't elaborated my proposed mechanism yet (it has a number of layers and distributed controls), it does have some features in common with a hardware interrupt, but many differences as well due to the special nature of the internet.

I'm not using the term "interrupt" as in "being interrupted by anyone", but more in the hardware (and system software) sense of being able to enable an "interrupt" for *CHOSEN* information sources and events. I would note that hardware interrupts (and system software event triggers as well) have various "masking" features to give the "user" the control they need to accomplish their tasks to meet their goals.

The hardware concept of "interrupt level" and the system software concept of "queuing" are also applicable and mesh nicely with the way real people switch hats, modes, gears, etc. to vary the flow of information that they want to see presented to them.

You might assign a "noise level" to each feed you subscribe to, and then globally set your current "noise threshold" so that various feeds would automatically be suppressed as being too noisy for your current mode, but then automatically re-enabled when you decide to open the spigot for how much information you're interesting in receiving at the moment. This concept could be implemented via polling as well, but as the number of "channels" I have a potential interest in rises exponentially, polling becomes even more problematic.

Also, with the concept of Google Desktop Search, you'd actually LIKE to have fairly significant flows of information from chosen sources that gets cataloged by Google without you even having to see it rush by. Or you might want to catalog it all, but set up a filter for which items actually should pop up in email. All of that information would currently have to be polled.

Just to be clear... I'm not advocating an *identical* mechanism to hardware interrupts, but simply using hardware as an analogy.

There's no reason why real people should have to suffer as a result of really bad information architecture decisions, but today we're all forced to suffer. I find the lame excuses of lazy, misguided, and arrogant infrastructure architects to be quite offensive. The crazy thing is that we're currently at their mercy because so much of the internet infrastructure is fairly centralized (in a relatively small number of individuals). Someday, the internet software architectures really will be sufficiently decentralized and users really will have interesting choices that they can make.

In any case, thanks for the comments and for giving me a reason to elaborate at least a little more of my thinking.

-- Jack Krupansky