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

[Bryan Kearney]

Jason Guiditta wrote:
> ==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).  

Just curious.. why is this bad?


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')

Perhaps the graphs become a flash/applet? But nothing else?
> 
> == 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

In a complicated production environment, you may not be allowed to 
install this. Try asking out SOC guys to open up a wacky port for you.

> --- 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). 

Is the comet load on the server? I would assume not since there should 
not be too many folks using the WUI.

> 
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ovirt-devel mailing list
> Ovirt-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/ovirt-devel