There were a few unfamiliar terms on that blog post, such as the CometD project and the Bayeux protocol, and curiosity gave me a brain itch until I finally found time to do some research. I'll share some of my findings here, so that the reader may be better prepared for the webinar, should they choose to attend.
Everything is a solution to a problem, or so I like to think, so what problem does this CometD project solve? This stuff is all about providing a better user experience. It aims to make what's on the page more accurately reflect what's on the server. It aims to fill a niche solution space, a gap that is left unfilled by AJAX and client-side server-polling. It aims to be the yang of the yin that is AJAX and client-side polling. So, to better understand the need for the CometD project and the Bayeux protocol, we need to see precisely what is currently available to a software engineer that already has AJAX in his tool-belt.
AJAX! The ambiguous term that tech-wannabes used to describe a web page that felt responsive. These days, people have narrowed it's meaning closer to it's actual functionality, and HTML5 is the New Thing about which to speak ambiguously. Commentary aside, the part of AJAX that we are interested in is its ability to talk with the server. It has the almighty XMLHttpRequest object that can grab data from the server, which is normally triggered by either a user interaction,
<input type="button" value="Send AJAX!" onclick="jsFuncThatSendsHttpRequest();"/> <div id="ajaxResponse"> <-- The JS method will format and place response here -->or by long-polling, see this great example using jQuery.
Now, using Javascript like this works pretty well, but it isn't a very elegant solution. We're manually checking with the server every 500 milliseconds (or however long we set), and I'm sure the server gets annoyed when it keeps telling us that it's got nothing new, not to mention all the wasted bandwidth/requests! A more elegant solution would be to use the observer pattern, in which we tell the server, just one time, that we'd like updates, then when it actually gets an update, it sends the update to everyone subscribed, which would be our JS process.
And this is exactly what the CometD project is all about, it's a push technology of the long-polling variety. If a web server is compliant with the open Bayeux protocol, it uses the observer pattern to push updates to subscribers. In the case of programming on the Force.com platform, the platform will be able to handle a subscribe request by Javascript code on a Visualforce page. So, in summary, you can write a Javascript callback function on your Visualforce page that will be invoked with the new data every time a process on the server gets it. Nice!
You can see how this Comet model is the yang to the yin that is client-side AJAX polling. Now what we do with it is the question. GTalk, GDocs, Meebo are some specific examples that use Comet ideas, but other applications could stream financial data/sports scores or online gaming packets, both of which places the logic in the server instead of the client. It will be interesting to see how the introduction of HTML5's WebSockets will change the need for the Comet model. Some leading voices have said that all existing HTTP push solutions, such as the Comet model, are just hacks and that WebSockets will standardize it. Others, however, argue that each technology has its own solution domain and can co-exist with each other. No matter, because WebSockets is still not close to be supported in browsers as its specification and security model are still under debate, so if you are to choose a push technology today, and want it to be relevant for a few more years, the Comet method is your best choice.
No comments:
Post a Comment