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

[Jason Guiditta]

On Thu, 2008-07-03 at 12:45 +0100, Daniel P. Berrange wrote:
> Off-topic: please make your mail client insert line breaks in your
> messages to the likst.
> 
Apologies, used the web client, which apparently has some formatting
issues for plain text.

> 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. 
I think this is less of an issue than it used to be, but point well
taken, it could be extra complexity we don't need.
> 
> 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.

The main one I was concerned about here was the ExternalInterface class,
introduced in flash 8 to allow communication with the host html page.
As I mentioned, this is not support in gnash.  However, if we use this
just for charts, there is probably no requirement for that interface, so
it may not be an issue.
> 
> 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.
> 
Good point.

> 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.
If this is true, great, but I was not sure, since I have heard talk of
admins possibly wanting to be able to log in remotely (though if it is
through a vpn or something, may not be an issue either).  Just wanted to
make sure security was properly accounted for.

> 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.
> 
Sure, makes sense.  And just to be clear, I was not suggesting we draw
graphs in the applet, just use it as the transport mechanism for the
data.  The graph could continue to be drawn in svg or flash in that
scenario.

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

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

I have heard from some folks that the graphs would be the most important
thing to have close to real-time, possibly the only thing.  We are
already rendering them with svg, which gives us the ability to hook into
the svg object model and manipulate with javascript (including drilling
down into the data), though we are not currently taking advantage of
this.  Flash, of course, would give us the same thing, just in a
different way.

-j