Hello guys,
Looks like my E-Mail brought some excitement into the list :) First of all it was not my intention, I just wanted to share with you some of my thoughts. Second, I don't think that we will have something ready before the end of the year (depending on the resources I'll have). For sure, if some one wants to work into the same direction, you are welcome. I also want to add some of my thoughts about NX and X2Go. NX is obsolete. It was obsolete many years ago. Xorg is becoming obsolete as well. And X2Go is already obsolete too, because we are sticking to this technologies way too long. Don't understand me wrong, those are great technologies, which will be used for many years more by some people and companies, we should not drop their support and we should not stop to improve them. But we also should not things like NX slow down our development. Because majority of the users don't want NX. They want to use modern desktops and modern applications. And they don't care, that NX works better with legacy desktops and legacy X11 apps on 256K network, because they are not using them anyway and they have at home in worse case 10M network and even on their cell phones they have a good Internet connection.
@Stefan: I think it's great, that you finding sponsoring and it helps to support the project. But we also should not forget, to separate the wishes of our sponsors and our customers from that what is good for the project. We can't concentrate only on that what our sponsors want, because in this case at some point they'll be our only users. We should also think more about future and what should we do to win new users to the project.
At the end I want to give you some points I think I will work on in the next one or two years:
regards, Alex
Am 07.05.20 um 04:15 schrieb Stefan Baur:
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
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder