Editor’s note: With all of the debate lately between RSSCloud versus PubSubHubbub, we wanted to hear from a developer who could actually tell us which one might be better and why. The following guest post is written by Josh Fraser, the co-founder of EventVue, who is an active contributor to PubSubHubbub in his free time. He has contributed several client libraries for PubSubHubbub including a WordPress plugin. Guess which side of the debate he falls on.
In the past few months, a lot of attention has been given to the rise of the real-time web. The problem is that the web wasn’t designed with real-time in mind. There is a huge need for the tech community to get behind new protocols that will power this fundamental shift in how web applications work. Today I want to take a look at two of the leading protocols that enable real-time notifications on the web. While there are older protocols that enable real-time notifications like XEP-0060, PubSubHubbub (PuSH) and rssCloud are two new protocols which show a lot of promise of gaining adoption.
Both PuSH and rssCloud address a fundamental flaw in the way web applications work today. Currently, getting updates on the web requires constant polling. Subscribers are forced to act like nagging children asking, “Are we there yet?” Subscribers must constantly ping the publisher to ask if there are new updates even if the answer is “no” 99% of the time. This is terribly inefficient, wastes resources, and makes it incredibly hard to find new content in as soon as it appears. Both protocols flip the current model on its head so that updates are event driven rather than request driven. By that I mean that both protocols eliminate the need for polling by essentially telling subscribers, “Don’t ask us if there’s anything new. We’ll tell you.”
Dave Winer deserves the credit for coming up with the idea long before anyone else. In fact, the <cloud> element was added to the RSS 2.0 specification in 2001, but has only recently been revived (largely in response to the interest in PuSH). rssCloud made major progress this week with the announcement that WordPress was adding rssCloud support for all 7.5 million blogs on WordPress.com. In contrast, PuSH is currently enabled for well over 100 million feeds with adopters including Friendfeed, Blogger, Google Reader, LiveJournal, Google Alerts and FeedBurner. I expect to see many more services adopt these new protocols soon.
But if you find yourself confused about how they are different, you’re not alone.
Conceptually, both protocols are very similar. Both add a simple declaration to a feed that tells a subscriber which hub/cloud has been delegated the responsibility of handling subscriptions. Both protocols have a centralized hub that notifies subscribers when new content is published. Both protocols are HTTP based.
The subtle differences in implementation are important to understand, however. And in my opinion, PuSH is the better protocol for now. There are basically three things that make PuSH a more robust protocol:
First, PuSH doesn’t just tell you that something changed, it actually sends you the new content (also known as a “fat ping.”) This is an important feature that is missing from rssCloud. Not only do fat pings make integration simpler for subscribers, they also eliminate the danger of inadvertent denial of service attacks as thousands of subscribers respond to the ping notification and request the updated feed at exactly the same time. This problem is well known in computer science and is often referred to as “the thundering herd problem.” While this would be relatively simple to fix in rssCloud, it has yet to be addressed.
Second, PuSH allows variable callbacks (custom URL’s for where the notification is sent) which rssCloud does not. The rssCloud specification states “Notifications are sent to the IP address the request came from. You can not request notification on behalf of another server.” This is highly limiting since you cannot separate the servers which are handling subscriptions from the servers which are receiving the ping notifications.
Third, PuSH has a more friendly policy for handling unsubscribes. In rssCloud, every feed is automatically unsubscribed after 25 hours. In PuSH, there is an explicit unsubscribe function with the option to automatically unsubscribe after a given amount of time. Again, this small detail matters a lot when you’re operating at scale. With rssCloud, RSS readers will be responsible for resubscribing millions of feeds every night – which is far less efficient than sending subscribe/unsubscribe requests only when something changes.
This isn’t to say that there aren’t benefits to rssCloud. It is far easier to implement an RSS cloud than it is to implement a PuSH hub. By design, PuSH hubs are not simple to implement.
There are other small differences, but these are the issues that matter most. Everything else boils down to semantics.
I want to address a couple of misconceptions that are floating around about both protocols. For example, many people think that rssCloud is simply about building a distributed alternative to Twitter. This is largely due to Dave Winer’s stated goal for rssCloud to create “a loosely-coupled Twitter-like network of people and 140-character status messages.” While that is certainly an interesting use-case, it promotes a very narrow view of the protocol and what it enables. I think rssCloud has far more potential than Dave gives it credit for.
The biggest misconception about PuSH is that it is somehow owned and controlled by Google. This simply isn’t true. Not only are there plenty of independent developers like me working on PuSH, there are also other PuSH hubs like SuperFeedr which aren’t controlled by Google. Brett Slatkin points out:
Our spec development process is completely transparent. You can see every code check-in since August 5th 2008. All discussion is on the public mailing list (there is no Google-internal one). The whole point of this spec is to be open, decentralized, and not in control of any company.
Overall, I believe that both PubSubHubbub and rssCloud represent a huge step forward for the web. While I personally believe that PuSH is a better choice, competition is always good and will make both protocols stronger.
(Photo credit: Flickr/Libertinus)
> The rssCloud specification states “Notifications are sent to the IP address the request came from. You can not request notification on behalf of another server.” This is highly limiting since you cannot separate the servers which are handling subscriptions from the servers which are receiving the ping notifications.
That’s the part that kills rssCloud as a viable format. Dave Winer basically said flat out at tonight’s rssCloud meeting that they won’t be changing the spec at all. This means that anyone with a distributed datacenter where incoming and outgoing HTTP requests end up on different IPs is basically hosed and won’t be able to subscribe to rssCloud-supporting blogs. Anyone on AppEngine is locked out of the rssCloud infrastructure, for starters.
Matt I was hoping to have app engine media subscribers (pshb/push & rsscloud). I think Dave may reconsider this.
Josh, you mentioned both protocols require centralized hubs. Isn’t part of the strength the ability to decentralized hubs?
Mark, yeah, you are basically dead in the water if you want to use AppEngine (or shared hosting, or another cloud service) with rssCloud.
I was pleasantly surprised how easy it was to get PSHB up and running in the cloud. With a few minor spec changes: beefing up the subscription API to prevent DDoS via rssCloud: http://grack.co...-vulnerability/, and allowing subscription of other endpoints that don’t live on your IP address, rssCloud may become a viable format as well in the long run.
I just hope rssCloud doesn’t win by default just because it has an easier name to understand compared to PubSubHubbub.
Betamax/VHS anyone?
Did Fraser just coin the word ‘PuSH’? The name ‘PubSubHubbub’ sounds…ahhh…interesting to a bunch of geeks, but ‘PuSH’ rolls of the tongue a little better.
I’m not sure who came up with it first but it wasn’t me. I do like it better though.
PuSH also explains in one word that it pushes new content to the reader.
Yes, it makes more sense than rssCloud.
Here’s the revision history: http://twitter....atus/3564346965
PubSubHubbub and rssCloud represent a huge step forward for the real time web. Whether 7.5 million or 100 million blogs do not matter. But making the real time is what is very much needed one.
The competition is good always.
Awesome article Josh. I fully agree with you on all points. I am a little scared that a “protocol-war” started between 2 open protocols. I think it is sad that both initiatives haven’t been able to “negotiate” and build on common grounds, but I guess it’s just that the history is repeating (Atom and RSS…)
PS: Thanks a bunch for mentioning Superfeedr!
Far too many of the limited (in depth long length) discussions I’ve followed so far sway to polarization around the individuals — which misses the points you’ve outlined above.
This is really about moving things forward.
Great post. This fact that the complexity of PuSH is in the hub and the subscribers and publishers are very simple, makes this very powerful. Do you see hubs evolving to provide more intelligent services going forward? Are there examples of PuSH usage for anything other than blog updates?
BTW PuSH sounds so much better :)
I think one of the key services that hubs can provide right now is handling polling for feeds that don’t yet support PuSH. As excited as I am about the new protocols, we’re going to need a stop-gap measure until we can get wide-spread adoption. A good example of a company doing this is SuperFeedr.
As you noted, PuSH isn’t limited to just blogs. It can be used for anything that is feed based. This includes many types of API’s like Flickr. We’re just starting to see the beginning of what is possible.
I personally hate the name PubSubHubbub. I’m doing everything I can to get people using PuSH instead. :)
Thanks, but since it’s case sensitive it’s not the most searchable. When I introduced it as an acronym I also suggested PuSHfeed – http://twitter....atus/3564346965
What if we drop the “u” and make it just PSH but pronounce it as “push”?
That gets around case-sensitivity and some ambiguity, but I’m not sure that would help the searchability that much. You want something more unique, not less.
PubSubHub is catchy and can still use the PuSH acronym. Just need to drop the final “bub”
I am using PubSubHubbub for days. I’ve built an app that real-time sync google reader shared item to twitter: http://reader2t...ter.appspot.com . It’s based on PuSH
Kang, Have you considered using XMPP to deliver updates directly to someone’s Jabber or GTalk client? If that sounds interesting and since you’re already using AppEngine, take a look at this example which provides the linkage in about a screen full of Java code… (A Python version would probably be shorter.)
http://grack.co...o-xmpp-gateway/
Note: Neither rssCloud or PubSubHubbub handle pushing data to client workstations behind firewalls. They both deliver results only to servers that can be accessed from the open web. But, hooking into protocols like XMPP is trivial to do — at least on AppEngine. Also, if you want XMPP delivery but don’t want to write all the code yourself, you can use Superfeedr which works with PubSubHubbub: (http://superfeedr.com/)
bob wyman
Aren’t most folks behind a firewall? So are push protocols currently useless? I’m confused.
Mark, A “push” protocol can’t push data to a client behind a firewall unless the client is the one that establishes the connection. With protocols like XMPP, Comet, forms of Ajax, etc. what happens is that the client opens up a persistent connection to a server and then the server uses that connection to push messages when necessary. (Don’t worry about lots of open persistent connections. On the Internet, connections are “free”… and most modern servers can handle many of them.)
These constraints on push protocols don’t exist when you are pushing to a servers that allows incoming connections. (i.e. any server like an HTTP/web server). Thus, you will typically see one set of protocols that are optimized for inter-server communications (and use sender-initiated connections) and a different set of protocols that are optimized for server-to-client communications (and use recipient initiated connections).
bob wyman
Dave Winer is genius, but a flawed genius. His actions seem to lurch from a paranoia of conspiracy against him to an absolute fear that his legacy is unappreciated or revoked.
RSS has not involved because RSS is Dave. A lot of people put effort into ATOM to address that fact, and it look like it’s happening all over again. Such waste.
I personally love the guy, but if we could not do this all over again that’ll be great.
Dave is often correct in that ’simplest wins’ but that’s because he’ll force through what he want and to hell with the rest. That’s a double-edged sword, and those getting behind RSSCloud need to realize that – there is a good and bad side of Dave, and it’s pretty random on which side you’ll fall from one day to the next. Dave is the spec, and the sooner we deal with that in an honest way the better.
Does anyone else think the last ‘bub’ in the name is extraneous? ‘PubSubHubbub’ looks like a random jumble of letters while ‘PubSubHub’ is much easier to grasp. Maybe they were inspired by the British band Dananananaykroyd?
Hubbub definitely has a different meaning than hub.
“loud confused noise from many sources” : wordnetweb.princeton.edu/perl/webwn
You can consider the final “bub” as essential to the meaning.
That said, I think the name really is bad. I can never remember if it’s Pubhubsub, subhubbub, pubsubhubhub, or whatever. Now I’ll remember it because of PuSH, but prior to this morning, I just rolled my eyes every time I saw the name. Clearly not a marketing driven name.
So I’d like use PubBub for publishing client, HubBub for hub, and SubBub for subscribing client.
First off, I’m all for PuSH just as much as I am RSS Cloud. Both work perfectly fine and I’m looking forward to this debate. I’m sure it won’t die anytime soon.
Now…
“This problem is well known in computer science and is often referred to as “the thundering herd problem.” While this would be relatively simple to fix in rssCloud, it has yet to be addressed.”
You don’t have to notify all your subscribers at the exact same moment. Actually, it probably wouldn’t even be possible to notify hundreds or thousands of people at the same time, regardless of the protocol. If your server can’t handle the subsequent incoming hits, spread the pings out over a couple minutes. You wouldn’t be able to send 1000 simultaneous updates to PuSH hubs either, so this isn’t a drawback of the protocol. But remember, both of these are server to server protocols and are designed to talk to a few “hubs” or “aggregators”, not thousands upon thousands instantly.
“It is far easier to implement an RSS cloud than it is to implement a PuSH hub. By design, PuSH hubs are not simple to implement.”
And that is the reason I think RSS Cloud has a big advantage. RSS won out over ATOM because not only was it the first, but it is dead simple. For those that don’t remember, RSS = Really Simple Syndication. When it comes to expecting the community to develop and evolve a protocol when there are many to choose from with little differences, I’d put my money on the easier implementation method.
One major misconception people have towards RSS Cloud is that “It doesn’t scale”. As you mentioned, Dave has planted the seed in peoples’ minds that RSS Cloud is secretly a Twitter killer, so people expect it to be able to scale to millions and millions of people to accomplish this goal. Well, shocker, it can’t, and neither can PuSH. Twitter is -still- trying to figure out scaling issues 3+ years in. I address this misconception in post I recently wrote @ http://www.dere...-will-catch-on/
Here’s a scenario where PuSH falls flat on it’s face in my opinion… Say you have a hugely popular blog and you are going to liveblog the latest Apple keynote. You have 50 messages per minute that your subscribers’ “hubs” need to be notified of. With PuSH you have to POST all 50 messages to the hubs. You don’t have a choice for them to get all the content in the correct order. With RSS Cloud you have the option of determining when to POST to your subscribers’ “Aggregators” and you can schedule that at once a minute. Do the math on that and you’ll see that RSS Cloud is a much more efficient protocol in that scenario when used properly.
Derek:
I think you missed some essential details about how the PubSubHubbub protocol works. Please look at the introduction presentation if you haven’t already: http://docs.goo...4mh2_34dvbpchfs
To clarify, everything in this paragraph (re:Hubbub) is incorrect:
“With PuSH you have to POST all 50 messages to the hubs. You don’t have a choice for them to get all the content in the correct order. With RSS Cloud you have the option of determining when to POST to your subscribers’ “Aggregators” and you can schedule that at once a minute.”
1. Ordering of XML elements in Atom or RSS is irrelevant by definition. The date fields are used for ordering.
2. Hubs pull the full feed content from the publisher to compute what’s changed. The publisher does not push content to Hubs directly. Thus a single GET request may find 50 new items.
3. The publisher chooses when to ping the Hub, it can be once a minute, once per second– whatever.
There’s more, but I think you should take a more detailed look at the protocol spec first:
http://pubsubhu...b-core-0.2.html
“2. The publisher does not push content to Hubs directly. Thus a single GET request may find 50 new items.”
Ok, now I’m really confused. I thought with PuSH, the publishers actually pushed content to the hub? If my understanding of the pushing is incorrect, the yeah, points 1 & 3 are definitely affected as well.
What you described sounded much more like my understanding of RSS Cloud. I’ll certainly take you word on it though. I’ve watched the presentation a few times, but will dig into the spec a little more.
No. In PuSH, publishers only ping the hub saying that there is new content. The hub then fetches the feed, does a diff on it and pushes the new content to each subscriber. Having the hub fetch the feed is important because it eliminates the possibility of spoofing. This is another example of how the hub does all the work to keep things as simple as possible for publishers.
That makes sense. Let me see if I am understanding this a little more clearly now….
So there is virtually no difference between RSS Cloud and PuSH in terms of communication between publisher to hub/aggregator? With both protocols, the publishers ping the “hub” (PuSH) / “aggregator” (RSS Cloud), and those in turn pull down the feed. From that point on is where the differences lie. With RSS Cloud, nothing else happens. With PuSH, the diff of the old and new is then pushed to the subscriber?
Obviously there are lots of subtle differences, but from a high-level, am I understanding it correctly now?
Thanks Derek & Josh, while it’s making sense the flowchart really helps illustrate how each part of the system works (http://code.goo...p/pubsubhubbub/ presentation).
We want many hubs to allow for very fast information distribution.
The Internet is becoming a huge a shared state, and we all want to have instant access to changes to parts we care about.
“RSS won out over ATOM because not only was it the first, but it is dead simple.”
The Atom syndication format is a simple format that’s easy to produce and to parse. It’s also simple in other important ways — the spec is clear, the revision process is spelled out, and the ownership is clear. I like RSS and use it all the time, but Atom’s not complicated at all.
Fantastic post! Really informative and easy to read.
Can we please have more of these on TC as opposed to the ‘Gmail got 4 new themes’ type.
+1
… or the whining about iTunes or Apple?
OK to report on stuff and present great articles like this but stop the whine, it’s deafening.
+1 or a new irrelevant app revolving around twitter was released.
I’m expecting a Guest Post rebuttal by Dave Winer in the coming days. Good to see the next phase of the web heating up. Welcome to the real-time web!
I hope so.
Excellent and informative post. Thank you.
Don’t leave out AMQP. Though the HTTP/JSON side of it is still fairly newish, it’s amazingly easy to setup, cluster, scale, and use — and doesn’t dictate what your application workflow -has- to look like. (Ie: it supports publish/subscribe just as well as queues.)
I disagree with you on almost all points.
Sending the content with the update is a bad idea.
The client might not want the update right away. They might not fetch the full content at every update.
The denial of service problem is easy to avoid. For example under PUSH let’s say you only have the bandwidth to push out to 100 subscribers a minute. Using a “skinny” notification service like rsscloud you can just limit yourself to sending out 100 notifications a minute. Control the load by controlling the frequency that you send out updates instead of letting your bandwidth determine it for you.
As for allowing updates to be sent to a different IP address from the one requesting the notification. That opens the real possibility of DOS abuse.
I also think it’s a good idea to force subscribers to re-subscribe to feeds regularly, you cannot trust your subscribers to tell you when they stop subscribing that’s crazy.
1. Choose 1000 blogs that update regularly.
2. Send them all a request to send you a fat ping when they update providing your targets IP address.
3. Profit
Your target is totally screwed.
They get DOS’ed with huge chunks of data from 1000 sites.
The denial of service goes on indefinitely because they have to individually contact each site and request to be unsubscribed.
It’s like the old TCP DOS attack where you would send out a broadcast ping with a spoofed reply address.
Protecting against DoS attacks is an essential part of the PubSubHubbub protocol’s concept of subscriptions that must be verified. Please read the section of the spec that describes this:
http://pubsubhu...tml#subscribing
Also, 100 notifications per minute is too slow. We’ve used PubSubHubbub to do real-time chat in place of IM and it’s responsive enough. Consider the goal of 1,000,000 updates per second per hub. How does that change things in your mind?
Brett, absolutely.
rssCloud’s subscription model is vulnerable to all sorts of interesting attacks because it doesn’t verify anything but a “200 OK” from the endpoint of a subscription request. Couple that with these implementation bugs I found and reported earlier this week in WP rssCloud and Dave Winer’s own hub that allow you to subscribe arbitrary websites to their hubs. It’s becomes obvious very quickly that some sort of PSHB-style subscription challenge is necessary.
I tried to keep an open mind while evaluating both of these protocols this week, but PSHB won out over rssCloud very quickly (my evaluation and experimentation was blogged at the my website link above). I was able to bootstrap a XMPP gateway for PSHB in under an hour on AppEngine. The same gateway is impossible to write for rssCloud because the API is poorly constructed.
The PSHB guys (like Brett above) are doing a great job building their technology while trying to avoid getting sucked into the unnecessary politics here.
“It becomes obvious very quickly that some sort of PSHB-style subscription challenge is necessary.”
Total agreement here. Adding this to the rssCloud protocol would allow subscribers to specify alternate IP addresses for pings, avoiding rssCloud’s same-IP-subscribe problem. This has to be solved for rssCloud– I can’t see any other possibility, given that end-users aren’t the subscribers in these architectures; data centers acting as proxies are.
Hey Brett,
I have been considering a cloud based shared/distributed database that has many windows (interfaces) and merge concurrent changes.
In your expert opinion would pshb be faster than this sort of architecture for massive user numbers? Or would it be a more distributed solution?
I’m thinking about massive state sharing for social media/info distribution.
Exciting times, all this real-time web stuff has the potential to completly change the way we interact with the Internet. Although I cant help thinking that a constant and live interaction with the Internet is not nescessarily a good thing, its just gonna make us more dependant on it, isn’t it ok thw ay it is at the moment? What ever happened to patience?
Great article! real time web will start a slew of new application.
Christ, this site is pathetic.
Great piece, Josh. Thank you for contributing to the discussion about how both of these protocols aim to re-wire the web into a more real-time system. I’m looking forward to seeing how the protocols evolve – and I’ll be installing both your WordPress plugin and the one for RSS Cloud into my WordPress sites.
Thanks for writing this piece.
very nice!
It’s amazing that Dave Winer came up with this idea back in 2001 and i give props to him for fighting to keep things open and decentralized. However, as a developer, i agree with Josh that PuSH is so much better and hope that wordpress adopt it as well.
Matt Mullenweg has said they are planning on adding PuSH support as well.
Well, Dave Winer only came up with the ping part in 2001. He forgot the whole subscribing part until he saw PuSH and we explained to him that he was only 50% there.
(Apologies if that sounds rude, but I’m a little annoyed that Winer decided to start a pointless, misdirected format war instead of working together with the rest of the community… *sigh*)
There’s unlimited canvas space for you gents to share your art. No harm in Dave doing his own thing. I can subscribe, publish, and be a happy hub for both (or potentially many other) architectures.
Great article. If I were writing the new Google Reader, or Feedburner, or River2, this article would help me decide on a protocol to adopt. But from a publisher’s perspective, it doesn’t answer a very important question: Can publishers adopt both protocols?
If I am reading this correctly (and I may not be because I just skimmed over the wordpress plugins, rsscloud.org, and code.google.com/p/pubsubhubbub/), from the publisher’s perspective, rsscloud simply adds a element to the rss feed while PuSH adds and elements.
So, can PuSH and rssCloud co-exist in a feed?
Yes, absolutely.
I think this article misses some crucial elements in the rssCloud spec that erase the author’s concerns over the “thundering herd” issue. Specifically, rssCloud’s implementor’s guide at http://rsscloud...alkthrough.html describes “Saving the feed through the cloud”, which off-loads all subsequent subscriber requests for content to a 3rd party (indenti.ca in the canonical implementation).
So the only significant difference has to do with hub implementations and the “size” of the ping. “Fat ping” is NOT always desired, especially for small or bandwidth constrained end user devices. IMO, it also greatly increases the complexity of implementing a hub based on PSHB.
There’s a summary document (Google Docs) I did yesterday on what it would take to normalize the two methods available at http://tinyurl....om/rsscloudPSHB
Comments welcome.
Chuck,
Your document is a good resource, but it basically covers the same points as this article here. It also glosses over the major shortfalls in rssCloud, like the requirement that your endpoint live at the same IP that your request was made from. As I mentioned before, this makes running rssCloud a non-starter in some hosted and virtualized datacenters (ie: AppEngine).
The “complex hub” argument keeps coming up, but there is never any supporting evidence that shows PSHB being orders of magnitude more complex. In fact, this “feed diff” that makes the protocol more complicated is the same feed diff that every aggregator does today.
Unfortunately, your argument for “small” or “bandwidth constrained” devices falls over pretty easily as well. Under rssCloud, the mobile device is required to download the *whole feed* after every ping (vs. getting the incremental updates under PSHB). Additionally, the mobile device has to do all the work of feed diffing itself, instead of letting a PSHB hub do it for it.
“Feed offloading” is basically what FeedBurner does today. It doesn’t solve the thundering herd problem: it just pushes it to a different server. The clients are all going to have to get the feed anyways. They’ll just all charge at rpc.rsscloud.org instead of the original source.
Chuck Shotton wrote:
““Fat ping” is NOT always desired, especially for small or bandwidth constrained end user devices.”
This is totally irrelevant. Neither rssCloud nor PubsubHubbub send anything to “end user devices” since those devices will, inevitably, not have exposed IP addresses — they will be behind firewalls.
To get data to end-user devices, an intermediate server is required. That server would then either be polled by the devices or would push data to them using XMPP, Ajax, or something else. So, the interesting question is “How best to get updates to the intermediate server?” Push works great. Polling sucks.
bob wyman
I’m not suggesting that these two protocols are useless, but is no one going to question the basic premise of this post? That they “address a fundamental flaw in the way web applications work today” and that polling is “terribly inefficient, wastes resources, and makes it incredibly hard to find new content in as soon as it appears”? There is already a protocol that goes a long way to address this; it’s called HTTP.
I refer you to the source: http://roy.gbiv...-hidden-dragons
Anyone wants to work out a push system using http://www.appn...tifications.com API to push them on iPhone’s users? Let me know!
Dave Winer didn’t invent pub/sub over HTTP.
Jon Udell describes a pub/sub product designed in 1999 here http://jonudell...2001-07-18.html
and Patent 7,155,477 which includes pub/sub over the internet was filed in June 2001
The patent is bogus. I was doing explicit publish/subscribe over networks as far back as 1983 — and I know I was not the first.
bob wyman
“over networks” is not “over the internet”
the patent is about pubsub directly into HTML + JavaScript
I tried to limit the scope of this post to just rssCloud and PuSH. The post was long enough already without me diving into a history of pub/sub implementations.
PuSH’s Fat Pings really helped when developing http://rssfall.com (which I just launched) – without them I would’ve had to build something to fetch feeds and find the differences myself, rather than rely on the data from the PuSH hub.
If a PuSH hub polls as well for you, a feed reader using it need never access the RSS feeds themselves. Potentially.
Bob Wyman is right. Pubsub has been around for a long time, done by lots of people.
As someone who just implemented XEP-60 over BOSH directly into browsers, I’d be curious as to Josh’s take on this ‘old protocol’ – I assume he didn’t mean that pejoratively – or did he?
These protocols are great at ‘pushing feeds’, but it seems to me that XEP-60 is a more generic model here. In fact, XEP-60 has an AtomPub-based spec called AtomSub that Bob Wyman is a contributor to.
Maybe someone can enlighten me here… sounds to me like more NIH and wheel reinvention…
Cheers,
- Bill
One of these concepts is incredibly easy and can be deployed pretty much anywhere.
One of them is not.
I will give you one clue: it’s not XMPP.
Yea – XML is extraordinarily difficult to implement, but even a dim bulb like me was able to grasp it after much study.
Thankfully, there are now an abundance of XMPP libraries such that I don’t have to toil down in the markup anymore. One function call does it all… right over deployable-anywhere HTTP…
Cheers,
- Bill
Cool, so I don’t have to make a bunch of modifications on my server so I can support XMPP?
That sounds sweet.
agreed, pubsub has been around forever.
but writing a document in 2001 which talks about adding a single tag to an XML format is not “invention.”
a working implementation of pub/sub over reverse-HTTP into web pages is.
Winer didn’t “implement pub/sub over reverse-HTTP” back in 2001. If you want to see early, documented use of “reverse HTTP” then look at the mod-PubSub apache plug-in that grew out of discussions in the IETF in the late 90’s on “Internet Scale Event Notifications” and the work of Adam Rifkin and Rohit Khare at what became KnowNow.com… (there are other examples but I’ll leave them out for now..)
bob wyman
[1] http://ftp.ics....ub/ietf/notify/
Although I’m totally in favour of having HTTP as the main skeleton of the net, I’m with Bob Wyman on this one : XMPP is a far more sane way of doing this kind of thing. Just do slightly-less-than-real-time echoes on the Web.
If I had to choose between PubSubHub and rssCloud on anything other than technical grounds, I’d probably have to opt for the latter, Dave Winer has had a very successful history of getting rubbish widely adopted.
Don’t forget, Brad Fitz has a pretty impressive track record too. He’s the guy who came up with memcached which is now used by just about every major application on the internet.
and OpenID too
Building upon Josh and a commenter by the name Bob, let’s just call it PSHbub (or PuSHbub for that matter).
1. It has all the elements of the original name and functions of the protocol: Publish, subscribe, hub, and even hubbub are well represented in there.
2. It is “search engine friendly” as it is a fairly unique term.
3. It even goes opposite to rssCloud in the capitalization ending in three lowercase letters.