One of the first things I noticed about the protocol is that subscribers are required to have an internet accessible URL for validating subscription registration and receiving notification pings. This is not an issue for the Google Readers and FriendFeeds of the world, but this does leave desktop RSS readers out of the party.

Also interesting to note is that there’s nothing that requires the hub to be a separate entity from the publisher. In fact, it could be very desirable for the publish to own the subscription hub. Besides removing one notification roundtrip from the protocol, it would also give publishers more control over how often to ping users on updates. Nothing in the protocol requires that a notification be sent every time, so it would be possible to only notify a subset of users in real time (perhaps the ones that pay), and others on a regular basis.

Depending on how deep your RSS Trivia knowledge goes, this might sound awfully close to the rssCloud element, but Brett points out that the key differentiator here is PSHB’s “fat pings“, that is, the entire updated content is sent as the ping to the user.

To reduce latency and polling, PSHB supports persistent HTTP connections from hubs to publishers, but it could use FriendFeed’s SUP protocol to detect updates as well.

Though solving slightly different problems, it’s interesting to compare the SUP’s and PSHB’s stance on polling. SUP obviously relies heavily on polling, despite drastically reducing the amount required. While PSHB has strong opinions against. Polling is certainly less error prone, in addition to being less efficient. For example, how does PSHB handle dropped pings to subscribers? I admittedly haven’t dug too deep, but I assume a reasonable amount of state must be maintained in the hub to handle these cases smoothly.

Ultimately the most valuable contribution of the entire project might be the two outspoken Google employees behind it. Already they are seeing some adoption. The pubsubhubbub demo at Real-Time CrunchUp announced launched FeedBurner support and showed prototypes of Blogger and Reader support. Having evangelists inside the company puts early adoption in other Google products much more likely, which in turn will give the standard much more credibility.

Google’s not the first to tackle this problem. ThinkFree and Zoho already have mature offerings. Hell, even Microsoft has their Office Live Premium ($39.95/month). Features vary (Zoho has presentations, MS handles mail and web only). There is obvious demand and interest for such a product. So why is has Google’s entry got enterprises lined up do hand over their data?

Just the name.

Google’s Vice President of Engineering Doug Merrill says that “for the first time, consumer-grade applications are good enough that they can be used by enterprises,” but he’s wrong. They’ve been good enough for a while. For the first time, the applications are backed by a big enough name that enterprises are willing to trust the provider, especially now that the company is asking a fee for the service – a marked departure from the typical web 2.0 business plan.

But not everybody’s ready to dump their exchange server and climb aboard the Google Apps train. There are three problems Google is going to have convincing most companies to switch.

Here’s the first: Google (or anyone else) is going to be hard pressed to match the flexibility of a thick-client productivity suite in a web browser. This is the number one reason people shrug off Google Apps. Some may counter and say “well, 80% of users only use 20% of the functionality,” but it’s never the same 20%. Chances are 80% of the users are going to be slightly annoyed that they can’t find [insert feature here], the other 20% won’t even consider it.

The fix? Well, it depends if you consider it a problem. Google doesn’t. Google has repeatedly said (even after the announcement of PE) that they aren’t aiming to take market share from Office. And there is absolutely no reason that the two can’t exist side-by-side.

I am willing to bet that within a year, Google will release a plug-in for Office that wires the current working Word/Excel/PowerPoint (presentations are coming – don’t worry) document right into Google Apps. Extrapolating, it’s only a matter of time before similar plug-ins are available for all the major productivity suites such as OpenOffice and iWork. Imagine no more file incompatibility issues, the filetype is always Google.

Problem Two: A good number of companies will not feel comfortable having all their sensitive business data floating around outside their network.

Instead of sending your information out to Google, bring Google in with your information (if it isn’t already). Google already offers Google-in-a-box search appliances. There’s nothing stopping them from just installing Google Apps on one of their machines you’ve already got in your wired up to your existing network if that’s what you prefer.

Problem Three: Connectivity

If your office makes the move to Google Apps and the connection to the web goes down, you’re effectively boned. And it’s even more frustrating if the outage is at Google’s end and out of your control. Salesforce.com has already run into this. Google’s 99.9% uptime may not be good enough.

But this problem has a solution on the way. Robert O’Callahan of Mozilla recently announced that Firefox 3 will support offline applications. Properly instrumented, users may not even notice the disconnection.

Where Google Apps will win
Features. New ones.

Google will easily convince CIOs everywhere with their $50/user-year price tag, but they’ll have a riot on their hands if the end users are frustrated by the experience. Google makes very user friendly software, but I’m more concerned about the temptation to try and match Word feature-for-feature and ending up with ones that translate poorly onto the web.

The key is to offer features that are useful, but that users can’t find anywhere else. Google’s already hitting this with their very well done Online Collaboration tool and the automatic revision history (something that should have been implemented in Office long ago).

I’m also excited to see what Google does with their APIs. Integration with the other SaaS movers and shakers such as Salesforce.com or CrystalReports.com will be a tougher feature to match at the packed software level. Expect people to jump the MS ship just for that.

Heads up to opportunists: Learn Google Apps APIs as soon as you can. I have a hunch that integration and migration to Google Apps will be problems looking for solutions in no time at all.