POST) or maybe three (if you are one of the few fancy people to use
PUT). It’s asynchronous and transactional. You want a push update. Forget it. You want a stream to listen to, not happening. Much of the things I build need synchronous interaction which we can’t really do if we keep polling for information via
GET requests. Is it ok just to fake it? After many a conversation with my colleagues, Elizabeth and Prabhakar who happened to be the panels cochairs for ACM WWW 2010, I really wanted to start thinking about what the next generation of the web should be and how we can build it?
So, last week at WWW 2010, I ran a panel entitled “What the Web Can’t Do” to address these issues. On the panel was: Adam Hupp (head engineer of the Facebook News Feed), Joe Gregorio (from Google and long time supporter of httplib2, REST, and web technologies), Ramesh Jain (UC Irvine and video guru), Seth Fitzsimmons (now at SimpleGeo with a past life at Flickr and Fire Eagle), and Kevin Marks (at BT former Googlite and Technorati).
Adam pointed out quickly that HTTP Long Poll works best for most applications. WebSockets might solve the rest of the gaps but one must consider this balance of latency and experience. The problem becomes how do we handle notifications, you can’t wake someone’s browser. To follow up, Joe reminded us (well me) the web is more than HTTP but rather a stack of technologies that becomes the whole browser experience. Furthermore, he cited HTTP to be Turing Complete (by the way, Turing began that definition with the phrase “Assuming the limitations of Time and Space are overcome…” which is the very nature of the problem with a transactional protocol and synchronous interactions).
Ramesh lead us from there into problems with interactive video online, and that we have no way to represent events in the stack (short of some SemanticWeb efforts which havent really taken full force, or as Naaman said are dead). Echoing this, Seth pointed out the current collection of the stack leads to privacy problems. If I delete a tweet from Twitter, it’s still in the search index of Google and Bing. Maybe the crawler will come to understand it should be deindexed and decached. Maybe!
Finally, Kevin Marks, who recorded the whole session using QIK [1, 2, 3] with a little help from his friend, pointed out the mess we are creating with no convergence. Pick an HTML5 browser and he’ll point out what video won’t work due to CODEC supports. More so, we traditionally handle these streaming connections through hidden Flash objects on the page; if we leave the plugin architecture in defense of open technologies, what will fill the gap?
At this point, I asked Joe Gregorio:
How come there is no
LISTENverb in HTTP?
To which he responded:
MONITOR. Actually it was in the original spec. It was abandoned because nobody could agree or figure out how it should work exactly. [NOTE: I’m paraphrasing here, cue the tape for the exact quote]
This floored me—an 8th verb! It’s like discovering there was a 5th Beatle or a 32nd flavor of Baskin Robbins! There was a verb at one point which would facilitate highly synchronous HTTP connections but it never made it to production. This all spoke to what Kevin was getting at: the issue is a combination of politics and technology. Seth and others on the panel started to conclude that OPEN technologies follow CLOSED innovation. In the case of the Web, we are are 2-12 years behind what should happen.
This is why now I can run Quake from 1997 in Chrome. HTML5 and Canvas does what Flash was doing years ago. As much as I would love it, running Dark Castle in a web browser, doesn’t help me very much. Furthermore, these technologies have never duplicated the other: HTML5 and Flash are mutually beneficial; they always have been. I’m not interested in building what I could have built years ago. If one’s to build highly interactive Web apps, then you have to sit closer to the metal, the chips, and the hardware. And while my panel was happy to tell me to wait because it will happen (perhaps
MONITOR will make a comeback), where will the deep innovation occur while the web plays catchup? We need to think about the whole ecosystem of the WWW and innovate it faster. Till then, I’m likely to be resolved to writing Objective-C iPhone apps against web services and other arbitrary sockets. Research shouldn’t ride shotgun; it should be behind the wheel.