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

[Daniel P. Berrange]

Off-topic: please make your mail client insert line breaks in your
messages to the likst.

On Wed, Jul 02, 2008 at 06:39:28PM -0400, Jason Guiditta wrote:
> = 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. 

In my experiance Java plugins are a real PITA - for example at one 
company I worked at, blade centers were using a Java plugin for their
remote console. Unfortunatelty this required a specific version of 
Java from a specific vendor in order to work. Another web app they
used required a different version of Java.  Spot the problem.

Java promises portability, but this is very hard to actually deliver
especially in the context of browsers where its hard to switch between
different installed versions. 

Flash has been much better at compatability - i've rarely found things
which were broken simply by the user updating to a newer flash release.

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

I don't think that's a serious problem for graphing at least. If the
web page containing the applet is authenticated with Kerberos SSO,
its no neccessary to repeat this with the applet. We would simply
generate a unique one-time key for the applet when generating the
HTML page and the server would validate this when the applet connects.

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

Well Kerberos isn't going to get across the firewall either so this
isn't an issue. We're only talking within scope of an intranet
and people don't typically have strict firewalls for purely
internal traffic.

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

I don't expect there is any Kerberos/GSSAPI support. At most I'd
expect SSL. I don't see this as an issue though because the web
page access is already authenticated & we can just use onetime
keys passed to the applet via the webpage.

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

I agree that we want a plugin approach if we want to have highly
interactive graphics. The things that discourage me from Java are
the pain wrt deployment on the client browser end in comparison to
flash. Second if you look at the major internet sites doing live
graphing (eg Yahoo and Google finance) they're all using Flash.

The limited open source flash support is a concern, but if we have access
to the source of the applet we use, then we can ensure it is written to
work within the scope of the open source flash support.

> 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'd just have the server render graphs as PNG and a slow (10-15 second)
refresh in javascript as a fallback for non-applet users.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|