[Ovirt-devel] [R&D] Breaking the Browser

Wed Jul 2 22:39:28 UTC 2008

==Part 1: The Problem == 

I have been asked to look into some options for how we might fulfill a requirement for the web application to have data pushed to it from the server (instead of polling, which was our short-term solution). This takes us one step further away from the traditional page-centric approach of the web. We are already essentially a 'single page' app, kind of on the line of web2.0 and ria (though I suppose the 'richness' could be argued at this point in time). Just to be a catch-phrasey dork, I am going to call our goal web2.1 (I think 3.0 is presumptuous, but we are trying to do more than just update some content dynamically, a la web2.0). What we really want to do is stream various kinds of data to the client (browser), basically in some sort of subscriber pattern. Here is a rough cut at a couple of use cases for this. 

Use case #1: 
* Situation: Joe Admin has given rights to various hosts to Tina Developer. Tina is currently viewing one of these hosts through the ovirt wui. While she is looking at it, Joe realizes she should not have access to this system, and it should in fact be located elsewhere. He makes the changes, so she should no longer see or have access to this box. 
* Requirement: Tina should immediately be notified that the host she was viewing is no longer accessible, be redirected to either her dashboard or some other default location, and her left navigation tree should update itself to no longer have that host (and any affected sub-hosts or storage, etc). 

Use Case #2: 
* Situation: Joe Admin has selected a number of devices to monitor on his dashboard. One or more of the items (graphs) show him up-to-the-second data that he wants to keep an eye on. 
* Requirement: Joe needs these graphs to be constantly updated (maybe even every second, or 'x' milliseconds') 

== Part 2: Possible Solutions == 

There are two main categories of solution here: 
1. 'Comet' - a variety of specific implementations, all using some form of standard http request, and requiring only javascript on the client side. 
2. Plugin-based TCP connection from the browser. 

Long-term there is another solution in HTML 5, but it is not yet implemented in any major browsers (well, at least the ones we are targeting): event-source. Basically, this is a new element that you will be able to put in your markup that a server can push data to at will. Very cool, sadly it is not an option yet. Here is a little extra information: http://cometdaily.com/2008/01/10/the-future-of-comet-part-2-html-5%E2%80%99s-server-sent-events/ 

Each of these solutions has their issues, both from a technical and standards-compliance side. Here is some more information for each. 

= Comet = 
* This term was coined by Alex Russell of the Dojo Toolkit ( http://alex.dojotoolkit.org/?p=545 ), and is meant to describe 'long-lived http connections'. 
* Primer on push technology: http://en.wikipedia.org/wiki/Comet_(programming) 

Pros: 
* No plugins needed, just native javascript (or the library of your choice) 
* Standardization attempt called the Bayeux Protocol. 
** pubsub protocol, data encoded in JSON. 
** clients can create a 'permanent 'connection using a handshake, or send one-off messages 
** reference: http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html 

Cons: 
* Too many long-lived connections to server can cause problems (as in slow performance or crashing of the browser in some cases). HTTP/1.1 specifies no more than 2 open connections per client, and this is enforced by the major browsers. From my understanding, this is why having things like google reader or gmail open for a long time slows down firefox (and probably others) 
* Bayeux Protocol - currently no ruby implementations that I can find, unless we want to use jruby, in which case, we could use jetty as the server, which does handle comet/bayeux 

= TCP = 
* Both Flash and Java can make TCP connections to a server from within a plugin and communicate with the host html page. 

Pros: 
* This has the huge benefit of being low-latency, low-bandwidth usage. 
* Would enable us to use a more standard client/server, pub/sub model 
--- Flash-specific: 
** If the pro-flash folks win out, and the graphs get moved to being flash, then using this for the tcp connection would mean one less plugin required on the client browser. 
** There is a rails plugin called juggernaut that does this (http://juggernaut.rubyforge.org/), though it uses it's own event-based server of the same name on the back end (based on eventmachine), not sure how that part would fit in with our messaging needs. Also, it is not very actively developed, and I was unable to get their example working (guess that is not a pro...) 
--- Java-specific: 
** Truly open source, will work on all platforms, once the bug (see cons) is fixed. 
** Could potentially, now or in the future, use jruby for the applet, so it would be more in line with the existing knowledge of our current developers. 
** Probably more friendly for firewalls/security. While not perfect, I read much less negative articles about use of tcp in applets vs flash (which has had _many_ security issues of late) 
** _If_ we wanted to, at some point we could use javafx scripting, though this is not even out in GA yet. This is Sun's entry into the RIA world, to compete with Flash and Silverlight (which of course I am not even reviewing, since it is an MS product). 
** Bindings exist in qpid for java/ruby, so we could potentially have easier integration for communication with the messaging system. 
** Java has support for kerberos, gssapi, and anything else we might need for auth-related stuff 

Cons: 
* _Really_ breaks the web standards, since it isn't even using http. 
* Open source versions of both plugins currently have issues with the communication between the plugin and the html 
--- Flash-specific: 
** Flash uses an actionscript class called XMLSocket for the TCP connections. One potentially major drawback for this is that it requires a port of 1024 or higher be specified. From my reading, this is a potential issue for corporate firewalls. 
** The player communicates with the browser (and vice versa) using the ExternalInterface actionscript class. This works fine on all major browsers with the adobe player (32-bit only, adobe still doesn't support 64), but according to Rob Savoye (the project lead) gnash can only support it through an 'extension', which does not seem to currently exist, nor could I find anything useful to help me get it working. If we wanted to go this route, we would need to write (and possibly maintain) such an extension, which I believe needs to be written in c++. Directions are here- http://www.gnu.org/software/gnash/manual/gnashref.html#extensions. We would also need to figure out packaging of that so it gets installed for the browser plugin. This is outside the realm of my knowledge, so I will leave it to others to discuss the feasibility of this option. 
** Didn't see anything on how to integrate flash with kerberos, gssapi, or any of the auth technologies we are using. 
--- Java-specific: 
** There is a java-javascript bridge needed for this to work, and does not have any problems with the sun plugin. However, there is a bug filed against the icedtea/openjdk version because this is not yet implemented (apparently it falls under some of the encumbrances sun has been trying to get rid of for the open source version). The good news here is that it is actually being worked on (http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#What_is_the_status_of_javascript) so this has the potential of being remedied soon, which gnash does not appear to have. 

== Part 3: Thoughts == 
Obviously I do not have final say here, but my feeling is that the best option is the applet approach with TCP (which surprised me, didn't think I would be advocating anything with applets, ever). I think the load incurred by comet makes it not a good option, and the security/plugin issues are making me less in favor of the flash approach (as well as quite possibly running into acceptance issues in the enterprise). Java is well-accepted there, has a better security model, _and_ is now open source. Of course, we know this means more people looking at bugs and fixing them, so security should improve even more with time. I like the possible integration points with qpid, and the future option of considering javafx for graphs should we move away from svg (still not in favor of those being flash). 

Another point is all of this can be done with the ability to fall back gracefully to lesser platforms. For instance, if java is not allowed, we can optionally fall back to either polling (much less often than we do now) or just updating the browser when the user attempts to perform an action that is no longer possible (like a vm no longer existing), providing a useful failure message and moving them to a sensible replacement location in the app. Similarly with the graphs, they could fall back to periodic updates, and if there was no svg support in a browser, we could even render the data values in a table, so they could still be somewhat useful. 

I look forward to hearing other people's thoughts on the ideas presented here, including any options that I may have missed or forgotten to mention. 

-j 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20080702/57d9277c/attachment.htm>