Yes, that is a limitation. I would be amenable to developing some sort
of in-app update mechanism for the TurboVNC Viewer, but it would have to
be a funded development project. I could also probably build a TurboVNC
Viewer package for Chocolatey or another Windows packaging environment,
but again, funded development. (Also, that would still require that
each user update the TurboVNC Viewer themselves. It would just be a bit
easier to do so.) I could also introduce a directive into the .vnc
connection info file that requires a minimum version of the TurboVNC
Viewer and prompts the user to upgrade their viewer if it is below the
minimum version, but I could see that being a tech support nightmare for
large organizations.
From a philosophical point of view, I was a fan of Java Web Start and
was sad to see it jettisoned, but unfortunately Oracle made its bed in
that regard many years earlier. Java was among several software
technologies that they acquired from Sun and tried to turn into cash
cows without paying much heed to long-term technological trends. When
Oracle refused to modernize the Java browser plugin, that led to a lot
of enterprises banning JREs over browser security concerns, since the
browser plugin was an inseparable part of the JRE. That significantly
reduced the ubiquity of the JRE, which significantly reduced the
relevance of JWS. Eventually, their only choice was to be reactive
rather than proactive-- jettisoning all of the web functionality from
the JRE and repositioning it as a runtime engine for standalone
applications (much like .NET is on Windows.) IMHO, they could've made
Java a ubiquitous language had they taken a more long view of it and
treated it as a strategic technology rather than a cash cow, but that
would have required giving it away for free-- something that Sun was a
lot more inclined to do than Oracle.
On 3/24/21 1:38 PM, Rafael Guimaraes wrote:
Ok, understood!
Today I've tested OpenJDK 11 with IcedTeaWeb and it worked with our
jnlp-based portal... However I think I will move to the .vnc-based
solution.
The only drawback of this solution, in my case, is that in order to
update TurboVNC to newer releases, I will have to update all my
clients... With the jws approach I only had to update the server...
Well, that's part of the game!
Thanks for the info!
Cheers,
Rafael
Em qua, 24 de mar de 2021 14:37, DRC <d...@virtualgl.org
<mailto:d...@virtualgl.org>> escreveu:
That depends on how the web portal is designed. TurboVNC web portals
tend to do one of two things:
1. The portal generates a .vnc connection information file for a
particular TurboVNC session and downloads the file to the client's web
browser, which passes that file to the standalone TurboVNC Viewer
installed on the client. Typically the .vnc file contains a one-time
password, generated by the portal for the TurboVNC session, so the
standalone TurboVNC Viewer can connect to and authenticate with the
TurboVNC session automatically.
This mode of operation currently works with all of the TurboVNC 2.2.x
Viewer flavors (Windows native, Windows/Java, Un*x, Mac) and will
continue to work the same way with the unified TurboVNC 3.0 Viewer.
The
only difference is that you won't need a separate JRE in order to use
the Java/Mac/Un*x TurboVNC Viewer.
2. The portal generates a .jnlp (Java Network Launching Protocol) file
for a particular TurboVNC session and downloads the file to the
client's
web browser, which passes that file to a JRE that has Java Web Start
capabilities. JWS then downloads the Java TurboVNC Viewer JAR files
from the portal's web server and launches the Java TurboVNC Viewer,
connecting to and authenticating with the TurboVNC session
automatically
as in (1) above.
Java Web Start is obsolete, from Oracle's point of view. Your only
options for continuing to use it in a production environment are
Java SE
8 and OpenJDK 8 + IcedTea-Web (ITW.) (OpenWebStart may also be an
option, but they don't appear to have enterprise support, and I don't
know anything about the quality of that solution.) Java SE 8 ended
public updates for commercial users in January of 2019, and Premier
Support for it will end in March of 2022, so the enterprise support
options for JWS are quickly disappearing. (OpenJDK 8 will probably
stop
being updated in that same timeframe.)
Thus, in TurboVNC 3.0, I've shifted the focus away from JWS and instead
developed the TurboVNC Session Manager, which provides a standalone
alternative to a web portal that will be suitable for most casual use
cases. Web portals that generate .vnc connection info files will
continue to be fully supported. Web portals that use JWS will be
supported only in a paid support capacity, and the TurboVNC 3.0 Server
no longer documents or facilitates that deployment method.
(Specifically, the TurboVNC 3.0 Server no longer provides signed
JARs or
an embedded web server, so enterprises that wish to use the TurboVNC
3.0
Viewer with JWS will have to package the TurboVNC Helper libraries for
Un*x, Windows, and Mac into separate JARs, sign those TurboVNC Helper
JARs as well as the Java TurboVNC Viewer JAR, and deploy the JARs using
a standalone web server and a dedicated web portal.)
The general mode of thinking here is:
- JWS isn't a "zero-install" deployment solution unless a JWS-equipped
JRE is universally available, and that is less the case these days than
it used to be. Generally speaking, only large enterprises can ensure
that a JRE is universally available on their client machines. From
TurboVNC's perspective, I can't rely on a JRE to be available.
- If a JRE isn't universally available, then it's a lot easier to
install a standalone TurboVNC Viewer than it is to install a JRE + the
Java TurboVNC Viewer.
- Thus, at least some of the session management functionality that was
previously implemented using JWS and web portals is being implemented
more directly in the standalone TurboVNC 3.0 Viewer, via the TurboVNC
Session Manager.
Also, it's worth noting that the Java TurboVNC Viewer relies
increasingly on native code in order to work around certain JRE
limitations. Specifically, native code is required for:
- High-speed JPEG decoding (all platforms)
This could previously be implemented with JWS by using the JNI JAR
files from libjpeg-turbo 1.2.x-2.0.x. With TurboVNC 3.0, however, the
high-speed JPEG decoder has been moved into the TurboVNC Helper library.
- Transmitting Alt-Tab and other special keystrokes to the server
(Windows, Un*x)
- Extended input device/drawing tablet support (all platforms)
- Multi-screen spanning (Un*x)
- Password-less SSH authentication (all platforms)
This is a new feature in TurboVNC 3.0.
If you're using JWS, then the embedded JRE in the TurboVNC 3.0 Viewer
isn't relevant to your use case, since you aren't using the standalone
TurboVNC Viewer to begin with. Nothing would prevent you from
continuing to use the Java TurboVNC 2.2.x Viewer with JWS. Just
understand that the support for JWS will become increasingly spotty as
time goes on. The first web portal that was ever designed around
TurboVNC uses .vnc connection info files, and that remains the best
approach.
DRC
On 3/24/21 10:07 AM, Rafael Guimaraes wrote:
> How will TurboVNC 3.0 work exactly without JRE? How will users be
able
> to launch the client when accessing a session through a web
portal, for
> example?
>
> Em qua., 24 de mar. de 2021 às 12:01, DRC <d...@virtualgl.org
<mailto:d...@virtualgl.org>
> <mailto:d...@virtualgl.org <mailto:d...@virtualgl.org>>> escreveu:
>
> No problems of which I'm aware. OpenJDK is the default Java
> implementation on Linux, so basically all Linux TurboVNC
users have
> been
> using OpenJDK for years. The evolving TurboVNC 3.0 Viewer
embeds a
> stripped-down version of OpenJDK 11 so it can work without a
> pre-installed JRE.
>
> On 3/24/21 9:57 AM, Rafael Guimaraes wrote:
> > Hi DRC,
> >
> > Have you ever faced any kind of problems when using
> TurboVNC+VirtualGL
> > through the Java Client running on Windows with OpenJDK
> 11+IcedTeaWeb?
> > We are planning to abandon Oracle JRE due to licensing
issues and I
> > would like to know if you (or someone else) have good or bad
> experiences
> > with OpenJDK+IcedTeaWeb...
> >
> > Thanks in advance.
> >
> > Cheers,
> > Rafael
>
> --
> You received this message because you are subscribed to the
Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to turbovnc-users+unsubscr...@googlegroups.com
<mailto:turbovnc-users%2bunsubscr...@googlegroups.com>
> <mailto:turbovnc-users%2bunsubscr...@googlegroups.com
<mailto:turbovnc-users%252bunsubscr...@googlegroups.com>>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org
<https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org>
>
<https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it,
send
> an email to turbovnc-users+unsubscr...@googlegroups.com
<mailto:turbovnc-users%2bunsubscr...@googlegroups.com>
> <mailto:turbovnc-users+unsubscr...@googlegroups.com
<mailto:turbovnc-users%2bunsubscr...@googlegroups.com>>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com
<https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com>
>
<https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com?utm_medium=email&utm_source=footer
<https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
--
You received this message because you are subscribed to the Google
Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to turbovnc-users+unsubscr...@googlegroups.com
<mailto:turbovnc-users%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/6fc02165-379f-c88f-71c1-dfef61767773%40virtualgl.org
<https://groups.google.com/d/msgid/turbovnc-users/6fc02165-379f-c88f-71c1-dfef61767773%40virtualgl.org>.
--
You received this message because you are subscribed to the Google
Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to turbovnc-users+unsubscr...@googlegroups.com
<mailto:turbovnc-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/CAMCG4_807%2BnaH_p22sBgJRrNyRuQPGJWJUWxa_jK_YVhUioFLg%40mail.gmail.com
<https://groups.google.com/d/msgid/turbovnc-users/CAMCG4_807%2BnaH_p22sBgJRrNyRuQPGJWJUWxa_jK_YVhUioFLg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "TurboVNC
User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/ee8eb0b1-9433-30ad-67bc-c69a7249e307%40virtualgl.org.
