Dare Obasanjo: "Remember all those rumors back in the day that Google was working on their own browser? Well they've gone one better and are working on the next Flash. Adobe likes pointing out that Flash has more market share than any single browser and we all know that has Flash has gone above and beyond the [X]HTML standards bodies to extend the Web thus powering popular, rich user experiences that weren't possible otherwise (e.g. YouTube). Google is on the road to doing the same thing with Gears. And just like social networks and content sharing sites were a big part in making Flash an integral part of the Web experience for a majority of Web users, Google is learning from history with Gears as can be seen by the the recent announcements from MySpace. I expect we'll soon see Google leverage the popularity of YouTube as another vector to spread Google Gears.
So far none of the Web sites promoting Google Gears have required it which will limit its uptake. Flash got ahead by being necessary for sites to even work. It will be interesting to see if or when sites move beyond using Gears for nice-to-have features and start requiring it to function. It sounds crazy but I never would have expected to see sites that would be completely broken if Flash wasn't installed five years ago but it isn't surprising today (e.g. YouTube).
For those who are not familiar with the technical details of Google Gears, it currently provides three main bits of functionality; thread pools for asynchronous operations, access to a SQL database running on the user's computer, and access to the user's file system for storing documents, images and other media. There are also beta APIs which provide more access to the user's computer from the browser such as the Desktop API which allows applications to create shortcuts on the user's desktop. "
Prediction: if Gears (or something like it) becomes ubiquitous (and it will), then eventually XMPP will become a protocol option alongside HTTP, allowing data to be pushed down into the client.
4 Comments
That would rock. I hope they do it!
What is the mojo that lets XMPP 'push' to the client where HTTP has not been able to do so?
Is it some mechanism that the client initiates an outbound connection, then reverses the roles and becomes the server/listener?
Is it some security or trustiness aspect to XMPP that is unique? Or is it that there are more XMPP servers that scale better with persistent connections down to the client?
XMPP clients keep alive a TCP stream to their server, so messages can be pushed at either end. Both ends listen for messages once the connect is established.
XMPP uses SSL and SASL for security and authentication, which isn't unique, but known to work. The model is clients connected to servers, and the servers federate messages between them - a partially connected mesh of stars. It's assumed that the servers are trusted, and messages can be plain text inside them. Applications can encrypt or sign message contents as they wish above the XMPP layer if more security is required.
Once the stream is established, XMPP end-points send 'just' the message 'stanza' - a small chunk of self-contained XML - rather than HTTP having to send a load of headers for a client request and don't require polling to get new messages from the server, as some HTTP designs do. But there's no reason that XMPP should scale better as such - some of the XMPP messages are verbose (eg pub-sub), so the total load in terms of streamed bytes can be no better, and someone could choose to write HTTP servers and clients optimised for persistent connections. It's not the usage model that currently deployed HTTP products support, so won't be much use as current clients' may not allow the stream to be processed as it arrives (eg XMLHTTPRequest only provides the response after parsing it completely), but current XMPP servers and clients do let you work in that way, and adding something that does what you want is perhaps better that twisting something that doesn't quite.
What do you see as the causality here Bill? I'm curious what you see as the relationship between Gears and XMPP.
Also XMPP is a viable option already; one can use BOSH or a number of other HTTP transports for XMPP. So, your bet seems safe to me. ;)