

RSSCloud Vs. PubSubHubbub: Why The Fat Pings Win - curio
http://www.techcrunch.com/2009/09/09/rsscloud-vs-pubsubhubbub-why-the-fat-pings-win/

======
TomOfTTB
The submitted link forgot the 'l' in cloud. Here's the actual link:
[http://www.techcrunch.com/2009/09/09/rsscloud-vs-
pubsubhubbu...](http://www.techcrunch.com/2009/09/09/rsscloud-vs-pubsubhubbub-
why-the-fat-pings-win/)

The article itself is worth a read. The only thing that bugs me is that the
author, and a lot of other people covering this story, don't mention that
RSSCloud doesn't support Atom at all (or more accurately it does in theory but
not in practice). I think that's pretty significant.

~~~
curio
Crap - don't know how that happened. I've reposted the article with the
correct link if you care to thumb that one up instead.

------
alexandros
The article mentions that the explicit unsubscription of PuSH is an advantage
over the implicit approach of rssCloud. With garbage collection being a major
problem of publish/subscribe in distributed systems, the author needs to
mention how PuSH deals with it in order to assert superiority. Without
acknowledging it, the credibility of the article is limited

~~~
curio
That's an important point. You can see how PuSH handles it here:
[http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-
co...](http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-
core-0.2.html#autorefresh)

------
juvenn
The coining word PuSH of PubSubHubBub is just ... marvelous

------
juvenn
That Bub part of PuSH seems as random bits. But I have got it used in:

    
    
      * PubBub for a publishing client;
      * HubBub for a hub; and
      * SubBub for a subscribing client.

------
msalvagna
I should think the reduced latency from receiving the data within the update
would be a greater benefit of a fat ping.

