{"action":"created","issue":{"url":"https://api.github.com/repos/TurboVNC/turbovnc/issues/147","repository_url":"https://api.github.com/repos/TurboVNC/turbovnc","labels_url":"https://api.github.com/repos/TurboVNC/turbovnc/issues/147/labels{/name}","comments_url":"https://api.github.com/repos/TurboVNC/turbovnc/issues/147/comments","events_url":"https://api.github.com/repos/TurboVNC/turbovnc/issues/147/events","html_url":"https://github.com/TurboVNC/turbovnc/issues/147","id":376961288,"node_id":"MDU6SXNzdWUzNzY5NjEyODg=","number":147,"title":"Java Web Start -- FEEDBACK REQUESTED FROM COMMUNITY","user":{"login":"dcommander","id":651941,"node_id":"MDQ6VXNlcjY1MTk0MQ==","avatar_url":"https://avatars0.githubusercontent.com/u/651941?v=4","gravatar_id":"","url":"https://api.github.com/users/dcommander","html_url":"https://github.com/dcommander","followers_url":"https://api.github.com/users/dcommander/followers","following_url":"https://api.github.com/users/dcommander/following{/other_user}","gists_url":"https://api.github.com/users/dcommander/gists{/gist_id}","starred_url":"https://api.github.com/users/dcommander/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dcommander/subscriptions","organizations_url":"https://api.github.com/users/dcommander/orgs","repos_url":"https://api.github.com/users/dcommander/repos","events_url":"https://api.github.com/users/dcommander/events{/privacy}","received_events_url":"https://api.github.com/users/dcommander/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-11-02T20:43:58Z","updated_at":"2018-12-04T04:15:59Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"As most of you know, TurboVNC (since v1.2) has embraced Java Web Start as a way of deploying the (Java/Mac/Un*x) TurboVNC Viewer in a zero-install capacity, and I know that some organizations use this method of deployment with their own internal TurboVNC web portals.  Although there is [some scuttlebutt](https://lists.openstreetmap.org/pipermail/josm-dev/2018-April/008023.html) regarding the open source community picking up support of JWS through the [IceaTea-Web](https://icedtea.classpath.org/wiki/IcedTea-Web) project, Oracle has dropped JWS from Java 11.  Thus, when public updates for Java SE 8 stop ([January, 2019 for commercial users and December, 2020 for personal users](https://www.oracle.com/technetwork/java/javase/eol-135779.html)), the only enterprise-friendly way of using Java Web Start will be through an Oracle support contract.\r\n\r\nIf your organization is currently using the TurboVNC Viewer with Java Web Start, I would like to hear from you regarding your plans.\r\n\r\n## Food for thought\r\n\r\nTurboVNC 3.0, which is currently being developed in the \"dev\" branch of our GitHub repository, includes the following new features that will ease the transition away from Java Web Start, for those desiring to make that transition:\r\n\r\n- The \"TurboVNC Session Manager\", which uses the Java TurboVNC Viewer's embedded SSH client to start, kill, and manage multiple TurboVNC sessions running under a particular user account on a remote TurboVNC host.  By default, the TurboVNC Session Manager automatically enables SSH tunneling and OTP authentication, for a completely seamless and secure user experience.  Once the user authenticates with the SSH server, everything else \"just works.\"  ssh-agent and Pageant support, for automatic SSH authentication using a key chain, are also possible but would require some additional development (preferably funded development.)\r\n- The Java TurboVNC Viewer is now deployed with a custom JRE on Mac and Windows, which eliminates the need to install a standalone JRE.  This custom JRE, which is built using jlink, includes only the components necessary to run the TurboVNC Viewer, so it requires only about 50 MB of disk space.\r\n\r\n## Ideas for a next-gen zero-install TurboVNC viewer\r\n\r\n1. Deprecation\r\n\r\n    Basically this would involve jettisoning the built-in HTTP server in the TurboVNC Server and supporting JWS deployments only from dedicated web servers and only as a legacy feature for Oracle Java 8 or IceaTea-Web users.  Originally the concept of an embedded HTTP server in every VNC session was predicated on the ubiquity of Java in web browsers, but these days, not only isn't Java ubiquitous in web browsers, but it isn't available at all.  My instincts say that the built-in HTTP server doesn't make much sense until/unless we develop some other type of browser-based VNC viewer that doesn't require Java.\r\n\r\n2. Hide and watch\r\n\r\n    Do nothing, wait and see whether IceaTea-Web becomes enough of a thing that it makes sense to support it along with the existing TurboVNC Viewer zero-install deployment strategy (including the built-in HTTP server.)  If OpenJDK+ITW binaries become available for Linux, Windows, and Mac, then it might become possible to support the existing zero-install deployment strategy, but still, it seems like:\r\n\r\n    - The only advantage of this would be the ability to push out new TurboVNC Viewer JARs to a large organization.\r\n    - Most large organizations that would need to do that are going to use a dedicated web server to do so, not the TurboVNC Server's built-in HTTP server.\r\n\r\n    In general, since desktop JREs are becoming less of a thing, the price for JWS deployment is installing more software on the client (i.e. a 200 MB JRE instead of the 50 MB TurboVNC Viewer w/ embedded JRE) and performing more steps in order to connect to a TurboVNC session.  The TurboVNC Session Manager, IMHO, is a much more straightforward workflow unless organizations already have a JRE deployed on all of their client machines.\r\n\r\n2. Keep the HTTP server but serve up a different viewer with it\r\n\r\n    We are looking at the possibility of a WebAssembly (WASM) TurboVNC Viewer in the long term, but WASM [doesn't yet support SIMD instructions](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/250), which are necessary for developing a TurboVNC viewer.  Another possibility is serving up a customized version of noVNC using our built-in HTTP server, although this would require a lot of work (and funding), and the resulting viewer would lack the features and performance of the standalone viewer.  The main advantage of using a viewer like noVNC would be support for mobile devices.\r\n\r\n3. Support [Webswing](https://webswing.org/)\r\n\r\n    Although I was able to get the TurboVNC Viewer to work with Webswing, with some modifications, in general the technology seems promising but not fully baked yet.  I ran into some deep issues, such as resolving some of the com.turbovnc.rfb classes, that shouldn't have happened.  The interface also doesn't work particularly well for mobile devices.  It would probably be necessary to implement a new \"Webswing\" mode, similar to the old applet mode, whereby the viewer behaves differently if it detects that it's running in a browser.\r\n\r\n    Also, given that Webswing works sort of like a VNC viewer, converting thick client apps into thin client, it seems like duplication of effort to run a VNC viewer inside of it.\r\n\r\n4. Support [Getdown](https://github.com/threerings/getdown)\r\n\r\n    This would restore the ability to deploy new TurboVNC Viewer JARs to a large organization, but it would take a lot of effort to integrate it into TurboVNC in a seamless manner.\r\n\r\n5. Some other idea I haven't thought of\r\n"},"comment":{"url":"https://api.github.com/repos/TurboVNC/turbovnc/issues/comments/443964962","html_url":"https://github.com/TurboVNC/turbovnc/issues/147#issuecomment-443964962","issue_url":"https://api.github.com/repos/TurboVNC/turbovnc/issues/147","id":443964962,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0Mzk2NDk2Mg==","user":{"login":"al3x609","id":4086644,"node_id":"MDQ6VXNlcjQwODY2NDQ=","avatar_url":"https://avatars2.githubusercontent.com/u/4086644?v=4","gravatar_id":"","url":"https://api.github.com/users/al3x609","html_url":"https://github.com/al3x609","followers_url":"https://api.github.com/users/al3x609/followers","following_url":"https://api.github.com/users/al3x609/following{/other_user}","gists_url":"https://api.github.com/users/al3x609/gists{/gist_id}","starred_url":"https://api.github.com/users/al3x609/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/al3x609/subscriptions","organizations_url":"https://api.github.com/users/al3x609/orgs","repos_url":"https://api.github.com/users/al3x609/repos","events_url":"https://api.github.com/users/al3x609/events{/privacy}","received_events_url":"https://api.github.com/users/al3x609/received_events","type":"User","site_admin":false},"created_at":"2018-12-04T04:15:59Z","updated_at":"2018-12-04T04:15:59Z","author_association":"NONE","body":"> 3a has been implemented in [6f4767e](https://github.com/TurboVNC/turbovnc/commit/6f4767ecf709310970f87744240b9e91cbdd4e33). That commit introduces two new options to vncserver that allow it to configure the noVNC WebSockets proxy as a substitute for the TurboVNC Server's built-in HTTP server. Conceptually this solution works the same as the existing \"zero-install\"/built-in HTTP server solution-- listening on Port 580x for HTTP/HTTPS connections from a browser and interfacing with RFB Port 590x on the back end. The major functional limitations are: (a) much lower performance than the TurboVNC Viewer, (b) no way to configure the encoding settings, and (c) only supporting VNC Password authentication. [38eb634](https://github.com/TurboVNC/turbovnc/commit/38eb634162834b9b4e8d195cdd711eddd9a49fd3) extends the TurboVNC Session Manager so that it can easily be used to generate new OTPs for a session and copy them to the clipboard, so this facilitates sharing a session using noVNC (or any other viewer that lacks the Tight and VeNCrypt security extensions) and logging into it using an OTP. Although that workflow doesn't make much sense if you already have the TurboVNC Viewer installed, it could be used to share the session with a colleague or to temporarily join the session from a mobile device or a different computer on the same network.\r\n> \r\n> Given this solution, I have retired the JWS documentation to the Java viewer README file, thus de-emphasizing that mode of operation but leaving it documented and supported as an \"advanced topic\" for the time being. It may make sense to eliminate the built-in HTTP server as well, but for the moment, I'm OK with merely deprecating it in 3.0 as long as it doesn't interfere with any new features.\r\n> \r\n> Bonus points will be investigating whether the TurboVNC Server can support WebSockets without a proxy.\r\n\r\nIf you put OTP over noVNC,  \r\nyou lose a feature that makes vnc notorious, persistent sessions; This is because the use of a web session is not only the opportunity of zero installation.\r\nIn this way, the user wants to start a vnc web session in X moment, disconnect and then reopen the same session in another place and / or device. With OTP, it requires again to launch the VNC server, which is not viable from the point of view of the end user in a remote service."}}
{"actor":{"display_login":"al3x609"}}