It was about 2.5 years ago now, that I joined Research in Motion – makers of the Blackberry – for what turned out to be the shortest stint of my career. I was brought in as their “Web 2.0” guy, though as part of the standards organization rather than R&D (which should have been a warning sign). My job, initially, was to write a white paper which described what RIM needed to do to embrace the Web. What’s the standards organization doing defining an R&D roadmap you might ask? Good question. I wondered the same thing. But that’s not what this post is about.
What it is about is that earlier this week, at the BBDC, RIM announced what is, AFAIK, its first on the topic of the Web; Web Signals;
BlackBerry Web Signals leverages RIM’s unique push technology to allow online content providers to automatically notify BlackBerry smartphone users when relevant content has been published and to allow streamlined, one-click access to the online information.
So I dug into the technical overview, and spotted this near the beginning;
To push content to users, content providers must first register their web signals with Research In Motion.
Bzzt!
As they don’t seem to realize, the Web is agreement; a large, complex distributed system made possible by parties who agreed to use its constituent protocols. Publishers agreed because it gave them a low cost path to distribute information directly to the users who had also made those same agreements (by using an agent which implemented the protocols). Imagine now, if you will, what would have happened to the Web, had publishers needed to register with, say, AOL to reach AOL users, or Comcast for Comcast users. What a huge burden! It could be worse, the burden could be on the users, but why bother with one at all? Remember PQA? My point exactly.
Always, always, always, try do what you need using existing agreement.
In this case – of notification of content changes – RIM had a couple obvious options. Most simply, they could have used email, though of course the user experience is suboptimal, not to mention the privacy concerns of handing out the user’s email address to every publisher. Alternately, there’s RSS/Atom, something publishers are already pretty comfortable with. It might even sound a little familiar, seeing as I described the architecture necessary to support it in that white paper I wrote for them.
If you’ve read ahead in that tech overview, you’ll also notice that they predefine their URI structure, and don’t even mention which HTTP method to use on those URIs to send a notification, which probably means that GET does the deed. Yuck.
Come on RIM, get your act together. Competition is heating up, and those guys in Cupertino (mostly) have their act together when it comes to the Web.
According to everything I’ve seen, the guys in Cupertino will be instituting exactly the same restrictions. More and better research please.
(For an alternative, see what the Android guys are doing with Jabber.)
(Full disclosure: I own an iphone, but know people on the android team)
Thanks, David. What do you know about what Apple’s up to? Obviously iPhone app development is wee bit proprietary, but I haven’t seen them try to offload iPhone-specific protocols on publishers like RIM are doing.
Android’s a mixed bag too. They reinvented a lot of mature Java APIs, and v1.0 integrates the browser into the OS the same way that people were doing it 10 years ago, so no innovation there. But on the other hand they are being good about using open protocols like Jabber, and that is reusing existing agreement. I would prefer to seem the use more of the Web though.
[…] somehow incorporate those wrappers into their code. Either way, there’s simply no chance of reusing existing agreements; instead, both sides require non-trivial […]