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

[Jeff Schroeder]

On Wed, Jul 2, 2008 at 3:39 PM, Jason Guiditta <jguiditt at redhat.com> 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).  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).

Cool, but... why? Why isn't having an error message and a graceful fallback
not good enough? You are describing a thick client not a web client. This seems
like something where 99% of the people would be ok with an error message and
ajax page updates that take them back to a dashboard. In saying ajax I'm meaning
dhtml that takes you back to the mainpage with no page refresh more
than anything
else.

This seems like a lot of extra work for a cool feature which wouldn't
be missed if it was
never implemented. Maybe you could implement a compromise with a
javascript timer
and a small data stream? Yes that is pull and not push based, but it would be:
- Easier to implement
- More compatible with existing mechanisms
- Not overly complex

Do you anticipate 10k different users connection to the wui at the same time?

> 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.
#2 shouldn't be considered if cross browser compatibility is to be considered.

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

My opinion would be the best solution is to not implement this feature until it
is supported via html5 in mainstream browsers.


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

For what it isn't really worth, strong NACK. Really good and forward
looking idea,
but not technically feasible in a clean standards compliant fashion.

It still is over my head why a pretty error message (something like litebox) and
a page refresh to the dashboard doesn't work. Time could be spent in
other places.
Building a thick-client in a web browser is one of the things that
killed the hula project.
The bongo project (hula fork after novell dumped it) is still plagued
by the rich web client
code-named "dragonfly". Whenever they edit it, things break. Ambition
is good, too much
is really bad, just my 2 cents.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com