Re: [VirtualGL-Users] Issues with the new Java applet

[DRC <dco...@us...>]

Correction to below:  "Cursor Shape Updates" is not a direct equivalent. 
  In the old viewer, it takes values of "disable", "enable", and 
"ignore".  The new "CursorShape" parameter is boolean, so it takes 
values of Yes/1/True or No/0/False, but the "ignore" option is no longer 
supported.

The other issue is that the class name has changed -- it's now 
com.turbovnc.vncviewer.VncViewer instead of VncViewer, so definitely it 
would not be possible to drop in the new viewer without changing at 
least that part of the web page.

Blah.  I'm beginning to think that backward compatibility may be a lost 
cause.  If it's necessary to edit the web page anyhow, I'd rather 
encourage portal developers to read the new parameter documentation, 
since it may reveal new features they want to take advantage of, or 
parameters whose behavior is subtly different (as above.)  If I were in 
that position, it would be much more confusing to me if some parameters 
remained unchanged but others didn't, and it wasn't documented which was 
which.


On 2/25/13 6:14 PM, DRC wrote:
> 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