[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391740#comment-17391740
]
Christopher Speck commented on GUACAMOLE-168:
---------------------------------------------
Hello Bernd,
What sort of issues did you run into? It should be possible to compile using
JDK 11. If you need to compile using Java 8 you can install JDK 8 side-by-side
with Java 11 and use the tooling from JDK 8 for compilation. Usually this
requires setting `JAVA_HOME` to the JDK 8 location which should cause Maven to
use the right JDK. Alternatively you can set up a separate system or container
just for building the war file and then copy it into the system that has Java
11 on it.
Be aware however that even though Java 11 is compatible with Java 8 the JRE/JDK
had several items removed or changed between the two versions. I don't think
anything in the gaucamole-client project has any reliance on these things but
it's something to be aware of in case it comes up.
> Add support for X.Org
> ---------------------
>
> Key: GUACAMOLE-168
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-168
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client, guacamole-server
> Reporter: Mike Jumper
> Assignee: Mike Jumper
> Priority: Major
> Attachments: 00-guac.conf, Xorg.0.log
>
>
> It's been frequently requested that we add support for a more efficient
> protocol like NX or X2Go. Though that sounds nice on the surface, and
> theoretically would allow us to leverage some of Guacamole's nicer
> protocol-level features, investigating deeper reveals:
> # X2Go *is* NX - it uses the same protocol behind the scenes.
> # NX isn't really a protocol - it is essentially a compressor for X11, and
> depends on the client having a local X11 server to handle the decompressed
> result.
> Implementing support for either of these would thus involve implementing
> support for X11, which is crazy. *However:*
> What about implementing a driver for the X.Org X11 server?
> The X.Org server provides a driver abstraction layer which exposes access to
> windows (including their hierarchy) and pixmaps, much in the same way the
> Guacamole protocol provides nestable layers and buffers. If we were to
> implement a Guacamole driver for X.Org, we would be able to make much greater
> use Guacamole protocol features like client-side compositing. Operations
> which are typically expensive in VNC or RDP like window movement suddenly
> become simple, as they only involve updating the properties of a layer.
> I have an experimental implementation of all this, built upon several other
> improvements which ended up being required. Work started several years ago,
> even before Guacamole was accepted into the Apache Incubator, but I think
> it's finally ready to move forward. I've been using it myself for roughly a
> month now, and so far so good.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
