Am 07.05.20 um 10:48 schrieb Mike Gabriel:
Again, that sounds nice as an add-on, but basic NX support in an HTML5 client should take priority. After all, that's what our sponsors asked for - and not a broker-/multi-server DMZ solution. It's fine to design the solution with a possible broker-add-on in mind, but please don't focus on the broker more than on the NX support.
Why stick to the NX support, if we have a native graphical backend that's html5 compliant.
Again: Because classic X2Go HTML5 support is what the sponsor wants to see. KDrive, Broker, Sound, Printer- and Filesharing - nice bells and whistles, but not what the sponsor wants.
NX is stable, NX is what they're used to, so they ask for it to be used. We're way past the stage where we could negotiate "Can't we just use KDrive instead of NX?".
I would also like to remind you that I don't consider KDrive production-ready for general use yet. It may work for Alex' customers, but last time I tried, I still saw quite a few quirks due to the session not recognizing that it is a remote session (showing popups that only make sense for a local user, granting permissions that a remote user should not have, etc.).
Those are blockers for a stable release and from my understanding, they need to be fixed in the Desktop Environments, not on the X2Go/KDrive side. And such changes are unlikely to get introduced/back-ported to already-existing long term releases of Linux distributions - which most sponsors/commercial users of X2Go are using.
So I doubt we'll see KDrive support becoming generally available until the next major releases of the most popular long-term distros. And that's not how long a sponsor should have to wait for a sponsored feature. Plus it might have a negative impact on their willingness to fund further work.
In a Pre-Corona world, I would have said I'd like to see results before or at the next Gathering. But if we get hit with another infection wave, who knows when the next Gathering will be, so that's not really an "anchor" for a time frame I would like to use right now. ;-)
The NX -> x11vnc -> NoVNC solution will always be worse (slower, more itchy and glitchy).
Maybe you could grab the NX output while still on the host (like, running a fake X2GoClient directly on the server), then push the output towards the HTML5 client the same way Alex' KDrive-HTML5 solution does? That could work as some kind of compatibility layer. That way, the DE would recognize a remote session (even though it's actually connected through 127.0.0.1 or ::1), so we don't have to deal with the quirks/wait for the fixes, yet you'd still only need one backend to talk to the HTML5 client, not two.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243