There is a lot of hype going around at the moment related to the wonderful functionality that websites will be able to offer once browsers implement the so-called "HTML5" features.
Some features should enable graphical capabilities without requiring a plugin (bye bye Flash), others are targetted at mobile devices - such as enabling the capture of an image from a camera.
The one that has been most relevant to my current project is Web Sockets.
In my opinion the key to Web Sockets living up to their full potential is that http servers must be able to support the model of keeping connections open.
At the time of writing, Apache httpd does not support this as it is architected for synchronous processing of requests and sending of responses.
Friday, 15 April 2011
Wednesday, 13 April 2011
Technical challenges streaming data over HTTP
I have recently been exploring options for enhancing the functionality of an existing website by integrating some streaming data feeds.
In the interests of making this functionality available on a wide range of devices (read iPads and iPhones as well as PCs) I would like this to be achieved without Flash or any other proprietary plug-in technology.
So, my old friend and foe Javascript is the lead candidate for providing the functionality on the client side.
Almost every article and blog post that I have read on the subject emphasises that client side polling is not appropriate, and that instead a continuous connection must be kept open between the web browser and the http server.
To avoid some of the challenges posed by Javascript's cross site scripting (XSS) security restrictions we would ideally push the data feeds out from the same domain name as the page that contains the feeds. For less data intense AJAX functionality this was made possible by hosting the servlet engine behind apache httpd.
Historically the way that most http servers have served their content involved dedicating a thread or process to serve each incoming request from start to finish. This does not scale well when incoming requests need to hold a connection over a prolonged period of time, so alternative approaches such as Comet have been implemented.
The Tomcat implementation of Comet is not supported when Tomcat is hosted behind apache httpd over AJP.
I was considering keeping the data serving system physically separate from the serving of HTML content anyway, so this restriction is just giving a friendly push to try using a separate sub-domain.
In the interests of making this functionality available on a wide range of devices (read iPads and iPhones as well as PCs) I would like this to be achieved without Flash or any other proprietary plug-in technology.
So, my old friend and foe Javascript is the lead candidate for providing the functionality on the client side.
Almost every article and blog post that I have read on the subject emphasises that client side polling is not appropriate, and that instead a continuous connection must be kept open between the web browser and the http server.
To avoid some of the challenges posed by Javascript's cross site scripting (XSS) security restrictions we would ideally push the data feeds out from the same domain name as the page that contains the feeds. For less data intense AJAX functionality this was made possible by hosting the servlet engine behind apache httpd.
Historically the way that most http servers have served their content involved dedicating a thread or process to serve each incoming request from start to finish. This does not scale well when incoming requests need to hold a connection over a prolonged period of time, so alternative approaches such as Comet have been implemented.
The Tomcat implementation of Comet is not supported when Tomcat is hosted behind apache httpd over AJP.
I was considering keeping the data serving system physically separate from the serving of HTML content anyway, so this restriction is just giving a friendly push to try using a separate sub-domain.
Subscribe to:
Posts (Atom)