==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>
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
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 htmlIn 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
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 stuffI 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 :|