You were correct about line 337. I applied your patch, and it seems to work now.
Regarding the parameters, they are case-insensitive, so "Port" and "Password" are still backward-compatible. As far as "Host", it's easy enough to add it as an AliasParameter. I want to talk about that first, though. Almost all of the Java parameter names have changed with the new Java viewer. This is so, when used as a standalone app, it will accept similar arguments as the Windows and X11 viewers. So adding "Host" as an AliasParameter would restore backward compatibility in only the simplest of cases. I could create aliases for other parameters that have direct equivalents, but that's only a partial solution as well. My concern is that it would provide a false sense of compatibility. I don't want to give the illusion that the new viewer is a drop-in replacement for the old. There are significant differences in its behavior that need to be considered by portal developers. Here is the mapping of parameters from 1.1 to 1.2: Unchanged: Port --> Port Password --> Password User --> User Direct equivalents: Host --> Server Allow JPEG Compression --> JPEG JPEG Image Quality --> Quality JPEG Chrominance Subsampling --> Subsampling Zlib Compression Level --> CompressLevel Cursor Shape Updates --> CursorShape View Only --> ViewOnly Share Desktop --> Shared Scaling Factor --> Scale No Unix Login --> NoUnixLogin Indirect equivalents: Sync Clipboards --> replaced with two parameters, RecvClipboard and SendClipboard Not implemented: EncPassword: straightforward to implement if someone needs it Use CopyRect: straightforward to implement if someone needs it Mouse Buttons 2 and 3: possibly straightforward Double Buffering: not relevant-- the new viewer is always double-buffered Scale Remote Cursor: not relevant-- this is done automatically Open New Window: not relevant-- the new viewer always runs in a new window Show Controls: could potentially be replaced with a "Restricted" parameter, similar to the "restricted" option in the Windows viewer Offer Relogin: not relevant Show Offline Desktop: not relevant Defer Screen Updates: not relevant Defer Cursor Updates: not relevant Defer Update Requests: not relevant AuthFactory: need the author of the class to port it to the new viewer SocketFactory: not relevant DEBUG_XU --> not implemented DEBUG_CU --> not implemented If you think that it would be valuable to supply aliases for the direct equivalents above, then I am open to that. Since it would require some testing labor on my part, though, I really would like to hear an argument for why this is a better approach than modifying the portal software to accommodate the new viewer. Also, I'd like to hear whether doing this would solve backward compatibility issues in specific circumstances, even though it would not be 100% compatible in the general sense. Another potential issue regarding backward compatibility is that AlwaysShowConnectionDialog is set to 1 by default when the Java viewer is used as an applet, and this causes the connection dialog to always pop up unless it is overridden by specifying <param name="AlwaysShowConnectionDialog" value=0>. As I ponder it more, I think it may be a better idea to have that parameter set to 0 by default but then add <param name="AlwaysShowConnectionDialog" value=1> to the version of index.vnc that we ship in the TurboVNC package. The effect for unmodified TurboVNC installations is the same, but for people that are using custom web pages to launch the Java viewer, it would make it behave more like the legacy Java viewer without requiring any modification to the web page. Comments? On 2/25/13 9:29 AM, Arthur Huillet wrote: > Hello, > > we have a use case where the TurboVNC java applet is started by a web > application. After trying to upgrade to the new applet, we encountered some > issues. > > First of all - the applet seems to force the target host to be the web server: > VncViewer.java line 337 host = getCodeBase().getHost(); > > This seems like a regression and I am not completely sure that this is correct > behavior. In fact, in our specific use case, the target host is *not* the same > as the web server, and the new applet doesn't seem to handle this. > Can anybody confirm this observation? Perhaps the attached patch should be > applied? > > Also, the input parameters to the applet seem not to be backwards compatible, > namely "HOST" is now "Server", "PORT" is now "Port" and "PASSWORD" is now > "Password". Not a big deal, but the change probably breaks more things than it > fixes. > > Opinions? > > Thanks ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
