7:19pmSandra

Hey Randy

7:21pmMe

hi

7:22pmSandra

how are you

7:22pmMe

fine n u?

7:22pmSandra

I am alright thanks

What exactly is the point of this conversation?

1. More and more Web 2.0 services that aren't monetizing, like MyBlogLog, will shutdown in 2010.
2. Twitter will max-out in 2010 and begin to fade in 2011. Like every other Web 2.0 service that didn't have a business model.
3. RSS will become just another Web protocol. Many people will claim it's dead, while unknowingly using software that relies on the protocol to do the research.
4. Twitter will finally get purchased by money; Google (very likely), Microsoft (less likely) or large media company turning Internet friendly (not NewsCorp). Twitter has topped out on valuation and can't grow without any revenues.
5. Facebook will remain private. They have earnings, never mind revenues. I can see rumors of an IPO in 2011.
6. Yahoo! and Microsoft will finally close the deal and merge. Expect a few more executives from Yahoo! to be pushed out first.
7. Windows 7 will spur a new (smaller and final) round of desktop applications.
8. Software developers who have been focused on creating cool Web 2.0 websites will take jobs writing accounting and financial software to pay the bills.
9. Google's Chrome will grow as a Web browser alternative and cut slightly into IE marketshare. Eventually (2011), it'll overtake Firefox as the Windows desktop browser alternative.
10. Google or Microsoft and many others will release Facebook knockoffs.

Sounds like a bad year for the Web.

http://www.therssweblog.com/?guid=20070101144441

http://ycorpblog.com/2009/11/17/owf/
http://tech.groups.yahoo.com/group/rss-board/message/295

In the meanwhile, Amazon suffered thru 3 months of my website being down. I lost a few bucks and Amazon lost a few bucks as well. Not a lot for me. Not a lot for Amazon, unless you consider that they had ten of thousands (maybe millions) of broken Web services, many of which generated substantially more sales than mine. What they did was chop off their longtail. The Long Tail is a theory put forth by Chris Anderson that the Internet generates an enormous amount of wealth/traffic/profit from massive amounts of low value services. Something to think about before you change your own established Web API.

http://www.hellosanta.org/

http://www.reblinks.com/

Both protocols are classic publish and subscribe. Publishers have a relationship with a hub. Clients subscribe to a hub. Publishers send updates to the hub. The hub pushes notifications out to the Clients. Nobody invented anything here, we've being doing this in computer science for a long time. Let's examine each of the four major interactions within the system; subscribing, unsubscribing, pinging and notification.

Subscribing

Subscribing is when a client tells the hub that it wishes to receive notification from one of its publishers. In this case, this might be a Web-based RSS aggregator (Google Reader) or a desktop RSS client (Feed Demon). In both cases, the client has polled an RSS or Atom feed and discovers that the feed has PubSubHubbub or rssCloud notification support. The client uses the information within the feed to send a simple HTTP request to the hub with varying parameters to setup the subscription. Very similar.

There are a couple small differences. PubSubHubbub only supports their REST API, while rssCloud supports all of XML-RPC, SOAP and REST. This would make rssCloud slightly more difficult to implement, as you have to account for three possible transports. Another difference is that rssCloud does not specify the target IP address of the client. Rather, it is assumed that the host of the request is also the notification target. You'll see later on that this makes implementing a notification gateway more difficult. The rssCloud protocol may include a parameter to allow passisng of the notification target's IP address in the near future.

There is one big difference. Because PubSubHubbub allows the subscriber to specification the notification ended, there is a greater possibility of malicious hackers or code subscribing a notification end-point against it's will. PubSubHubbub follows up all subscribing and unsubscribing requests by verifying with the client that their intent was true. The adds additional, but required complexity to PubSubHubbub. The rssCloud protocol may include subscriber verification in the near future.

Unsubscribing

Unsubscribing is when a client stops receiving notifications. With PubSubHubbub, unsubscribing involves the client sending a unsubscribe request to the server. With rssCloud, there is no request. Rather all subscriptions are automatically dropped after 24 hours. Don't think any of the two techniques are better than the other, there are advantages and disadvantages to both.

First off, I don't know anybody's software that is smart enough to unsubscribe when you close your laptop. Second, what happens when my laptop is closed and the hub is trying to send notifications? Are the notifications queued? How many failures before you unsubscribe the misbehaved (not really) client. Neither protocols is air tight and neither addresses numerous scenarios that arise frequently in homes and offices all across this Internet-enabled planet.

Ping

The ping component of both services are very similar. Both support a REST ping.

In addition to a basic REST ping, rssCloud allows the publisher to ping the cloud with all of REST, XML-RPC and SOAP. There doesn't appear to be a discover mechanism that tells publishers which of the protocols are accepted by the cloud, but this shouldn't be a much of a problem, since discover can occur via trial and error and the REST ping is likely to be supported by all rssClouds.

rssCloud does provide an additional lightly specificied interface that pushes the RSS feed to the cloud, allowing the cloud to host the RSS feed on behalf of the publisher. I highly doubt this would be widely used my many, unless the cloud implements more feed hosting services.

Notification

Notification is likely the biggest difference between rssCloud and PubSubHubbub.

rssCloud again allows for REST, XML-RPC and SOAP packages. This greatly increases the complexity of the cloud. The rssCloud notification is effectively a reverse ping, where the cloud ping the subscriber to tell it to fetch the feed and find out what changed.

PubSubHubbub implements a much more complex notificaton. It's not a simple ping, but rather an POSTed XML package contain the feed that has been updated, but with only the entries of the feed that are new or that have been updated. This creates an enormous amount of state problems within the hub.  What happens when the previous ping failed? Do you send multiple updates in the next ping? This could mean sending different notifications to the subscribers or subscribers missing new and updated entries. On the other hand, this will avoid flooding the publisher with simulaneous feed fetches from all the subscribers who've been notified of the change. Neither approach is optimal, neither is horrible.

Both protocols have a major failing, in that they rely on servers connecting to subscribing clients. If a client exists behind an unfriendly NAT or firewall, then the protocols simply fail. You can implement UPnP and other protocols and break your way thru some NATs and firewalls, but the problem will still exist on a large piece of the Internet pie.

Long Polling

Long polling is the solution to the NAT and firewall problem. Long polling is not the optimal solution to the notification problem because long polling involves holding open connections from the client to the server. This means 10,000 clients will hold 10,000 connections open. Yikes! The real solution is to detect the capabilities of the client and use direct notification where possible, UPnP where possible and long polling where everything else fails. It might be difficult to convince a developer of rssCloud subscribing software to implement UPnP when he can simply resort to long polling from the beginning.

Specification

One great advantage of PubSubHubbub is that it is tightly specified with lots of examples and code. rssCloud on the other hand is very loosely specified with pieces of code and text found in various interlinked documents across many websites.

Corrections

Please submit corrections in my comments or via email (randy@kbcafe.com) where this document is incorrect. Thanks!

Bibliography

• http://jy.typepad.com/jy/2009/07/pubsubhubbub-rsscloud.html
• http://grack.com/blog/2009/09/07/pubsubhubbub-vs-rsscloud/
• http://rsscloud.org/walkthrough.html
• http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html

Beyond simply the top Web hosts, they also provide reviews of Web hosting services in specific categories; multiple domain hosting, green Web hosting, vps hosting, dedicated server hosting, free domain names, free Yahoo! marketing and free Google Adwords. So, if you have these specific needs, then you can drill down directly to the hosting services that meet your needs.

The web host reviews on Webhostinggeeks.com also provides a section where users can submit their own rankings and reviews, and read those left by others. Some of the web hosts have more than a 100 reviews with a lot of great information. Many of the reviews are from review websites, but others are from geeks like you and me.

Webhostinggeeks also provides awards in various other categories; best budget hosting, best blog hosting, best forum hosting, best UNIX hosting, best Windows hosting, best PHP hosting, best email hosting, best ecommerce hosting, best multiple domain hosting, best vps hosting, best reseller hosting and best dedicated hosting.

Don't forget to check out their blog and subscribe to their blog feed. You can also subscribe to their blog using Reblinks to get emails everytime the blog is updated. Their blog is updated several days per week with new articles dedicated to helping webmasters make the best decisions when choosing web hosts. The blog entries include industry news, trends, products and discussions.

This is a paid review.

History of RSS

Why is RSS here? It's a pretty simple and stupid protocol based on polling to simulate push. Why didn't we just create a real push protocol? Why? You can't. Push doesn't work very well on the Internet. Some people will point you to email and instant messaging as push technologies that actually work on the Internet. Unfortunately, they are wrong.

Push Email?

Are emails pushed? Yes. They are pushed around the Internet between SMTP gateways and eventually land themselves in an inbox. An inbox. Not your desktop. An inbox sitting on a server somewhere. Then we opened our POP3 client and it pulled the emails back down to our email client. Or maybe we open a browser and pull the data down to our Web browser. Either way, email isn't only push, it's push with a bit of pull on the end.

Push Instant Messaging?

Are instant messages pushed? Sometimes. But even your Instant Messaging clients will fall back to clients connecting to servers using long polling, when push oriented connects from the server to the client fail.

Polling Wins!

You can't push. You can only poll. You can only pull. That's why push-based publish and subscribe technology failed in the 90s. That's why polling oriented technologies like RSS ruled the world for the last decade.

Enter Twitter

For nearly a decade, we were happy with the RSS solution giving us updates as late as an hour after publication. Life was great. Engineers weren't happy. Engineers hate polling. They want push. They want real-time RSS. They invented rssCloud. It died. Yes, rssCloud was invented a long time ago. They invented ping servers. Ping servers died. Then someone created Twitter, a centralized publish and subscribe service for micro-content. Geeks were in awe of the real-time immediacy of Twitter. Geeks were not happy about the centralized nature of Twitter. Geeks want the immediacy of Twitter and the decentralization of RSS.

Enter PubSubHubbub

Some of the engineers slash geeks that wanted real-time RSS worked at Google and they got together with the team at Google Reader and wrote PubSubHubbub. I think it was released in July of this year, but it may have been earlier. When I first saw PubSubHubbub in early July, I wondered how it was any different than previously failed pushing technologies (rssCloud specifically). If you read the spec, then PubSubHubbub is basically a copy of the rssCloud spec with some additional features meant to optimize, but that made it more complex and more difficult to implement than rssCloud.

Re-Enter rssCloud

I don't think Dave Winer was too impressed with PubSubHubbub, a knock off of his pre-existing and failed rssCloud technology. As such, Dave restarted the rssCloud movement and here we are today. Two technologies that are no different than everything that failed before it.

Who will win? Both? Neither? Someone? Somebody else?

If the notifications don't come streaming in, then your rssCloud service failed to automatically detect that the client was offline and queue the notifications. Or maybe the rssCloud didn't automatically detect that the client changed IP addresses. Or possibly there's a NAT at Starbucks that has to be configured to allow connections to the client from the server. Or maybe there's a firewall at Starbucks and your rssCloud service didn't automatically call starbucks and ask them to disable the firewall. Or possibly your software did call Starbucks and they didn't think the request was reasonable.

If you can get this scenario to work, then tell your son Jesus Hi for me.

Scenario 2

Now call up your corporate IT and ask them to open an incoming port for you, because you need rssCloud to work. If they deny this, then don't worry, it's not your software that's broken, it's the rssCoud protocol that doesn't work behind corporate firewalls.

Scenario 3

If she does know how to configure the wireless router, then you fail anyways because the intent of the test was to see if a mundane user behind a NAT could use an rssCloud client and your wife is a geek, not a mundane.

Scenario 4

This will make rssCloud easy to scale, since most users will not be able to use and only the few geeks capable of pushing load on the servers. The designers of rssCloud were thinking scalability when it was written.

Scenarios 5

Typed on cellphone, please excuse typos.

http://www.therssweblog.com/default.aspx?search=blogosphere+ping

I wrote about how it didn't work. Companies that relied on the ping, like Technorati and PubSub have stagnated and disappeared. That's because ping infrastructure requires big walls of servers and that costs a lot of money. Unless you have a business model to support this, then you have a company that's doomed from the start.

rssCloud reminds me of PinGoat and Ping-O-Matic. You send them a ping and they broadcast it to everyone else. I haven't heard much from either for the last while. Does anybody actually use these ping distribution services anymore? I stopped because I realized they didn't work. PinGoat would get 10,000 pings a minute and send 100,000 pings. Imagine that server load. In the end, these services did nothing, because they were too overwhelmed to do anything.

Imagine if one million Wordpress blogs started pinging, millions of users started subscribing and unsubscribing and notifications started getting sent all over the place. It would be scalability hell all over again. In fact, it would be worse. It wouldn't be just some ping servers bashing each other, it would be all the rss clients all over the blogosphere bashing the crap out of these rssCloud services. Open my laptop, my laptop registers hundreds of feeds. Close my laptop. The notifications fail and these servers start timing out like mad. Open my laptop. Does my laptop re-register? I likely got unsubscribed because of all the timeouts. I open and close my laptop a dozen times per day. No matter what, you have to re-register once per day. rssCloud needs a business model. Badly.

http://workbench.cadenhead.org/news/3555/theres-reason-rsscloud-failed-catch
http://techbrew.net/articles/200909/rsscloud-all-wet/
http://www.scripting.com/stories/2009/09/08/20022009.html
http://rsscloud.org/walkthrough.html

http://www.scripting.com/stories/2009/09/07/teaseTeaseTease.html

When you sell your baby to bigco's like Google, they get gobbled up into their infrastructure. Plans change. Branding changes. You don't here much about FeedBurner anymore because it's now just a piece of a bigger machine called Google. I don't think Google has any intent on closing down FeedBurner feeds. Where's the failure?

Interesting timing considering that Twitter has hired x-FeedBurner CEO Dick Costolo. Does Dave have something against Mr Costolo? That's a clever move for Twitter. FeedBurner wasn't Dick's first success. He and his team start-up SpyOnIt back in the 90s. They were purchased by 724 Solutions for $53M. Dick worked for 724 for awhile until his team left and started FeedBurner. I was one of the original employees at 724 Solutions. When I found out we bought SpyOnIt, I was extremely happy. It was an awesome technology. I can't wait to see what Dick does with Twitter. Put it thru the roof.

http://www.scripting.com/stories/2009/09/05/rssHasNoFailWhale.html

http://www.reblinks.com/
http://www.rssemail.com/

http://scobleizer.com/2009/08/26/rss-interesting-or-boring-hint-marshallk-and-louisgray-were-not-normal/

Scoble and Dave Winer see this as a short-coming of Twitter. I'm not as concerned.
http://scobleizer.com/2009/08/10/twitters-platform-shortcomings/
http://www.scripting.com/stories/2009/08/10/enoughWithShortenedUrls.html

Annoucement
http://blog.tr.im/post/159369789/tr-im-r-i-p

BTW, FriendFeed should be sending a cut of that $50 million to Robert Scoble. There's no way a geeky social Website is worth $50 million. Just another example of the Scoble Factor. Anybody here heard of Technorati? Six Apart?

Read Dave Winer for more on the Scoble Factor. Dave argues that the acquisition isn't user friendly. Interesting point. Personally, I always saw FriendFeed as a very geeky site. Only my fellow geeks use it. Non-geeks have never heard of it.
http://www.scripting.com/stories/2009/08/10/scobleYourBlogStillLovesYo.html

More...

• http://blog.friendfeed.com/2009/08/friendfeed-accepts-facebook-friend.html
• http://www.facebook.com/press/releases.php?p=116581

Announcement
http://tech.groups.yahoo.com/group/rss-media/message/1199

New Spec
http://tech.groups.yahoo.com/group/rss-media/files/

Old Spec
http://video.search.yahoo.com/mrss

Read more...
http://tech.groups.yahoo.com/group/rss-public/message/1915

http://tech.groups.yahoo.com/group/rss-media/message/1185