Anonymous quote: 
 "Any problem in computing can be solved with another level of indirection"

Unifies Push and Pull technologies (PushVersusPull).  The publisher publishes to 'channels' (push), the subscriber subscribes to 'channels' (pull), can have the benefits of both. 

Is a basis for Aggregation.

I am thinking more and more about it.
----
== Aggregation and Transaction Costs
There is a cost of checking a website for new content and that cost needs to be justified by the probability that there is some interesting update on it.  If not people will not come back to that source and eventually forget about it. 
This cost leads to websites pushing trivial updates just to keepe people coming to them (see [http://www.corante.com/getreal/archives/006040.html Talkativeness and Influence]).  This is a very bad economy worsening the noise pollution of the web. 

But it is quite a different story when the user does not need to check himself for the updates but when he is automatically allerted when there is such an update on one of his subscribed sources.  Here when a source is too noisy the user would eventually get bored by it's constant alerts and unsubscribe from it.   So the rational behaviour for news sources in this model is to allways encrease the SignalToNoise ratio and that is what we all want, n'est ce pas?
----
Links:
* [http://www.jabber.org/jeps/jep-0060.html Publish Subscribe in Jabber]
* [http://nowhere.2entwine.com/archives/000134.html PubSub and Jabber's Network Topolgy] nice quote: 
 "We've been saying all along that IM and syndication belong together,
 and the PubSub service is the server side extension to that vision."

* http://c2.com/cgi/wiki?PublishSubscribeModel
* [http://arch.jabber.com/archives/2004/04/000098.html Use pub/sub, not presence...] - overloading presence with information that is not strictly presence (like 'what music is currently played') is not good, better use the more general pubsub for that