It seems to be based on DXPC with more aggressive caching and some other improvements (e.g., it sends images in compressed form, breaks images up, and sends them at lower priority than window manager and other messages).
Their mission statement says that it should work with any server and any client.
It can also encapsulate RDP and RFB (VNC).
The biggest problem with remote access using X11 in the past hasn't been performance, it has been the difficulties of disconnecting/reconnecting applications.
Originally, this had been envisioned as an integral part of using X11, but it was the applications that were responsible for supporting it and they never did. Eventually, we got tools like "xmove", but they were too cumbersome for general use.
VNC succeeded so well probably not because of its compression (which is decent; in particular, it works with ill-behaved X11 apps like KDE and Gnome desktop apps), but because it made disconnecting and reconnecting sessions so easy.
Network transparent window systems have been in widespread use since the 1980's. RDP and Citrix are the typical "me-too" products in the Windows world, years late and not quite as good (but probably good enough to get the job done).
Note that remote desktops are not necessarily aimed at dial-up. For example, X11 was not designed to use the smallest amount of bandwidth, it was designed for a LAN environment and still is far better than either RDP or Citrix on a LAN. Raw X11 is not the best choice for dial-up, but in combination with something like DXPC or NX, it is good there, too.
And for the ultimate in thin clients, VNC is a great choice; VNC represents a completely different tradeoff in design parameters for remote displays.
Evas-based apps are at least 10 times more responsive than GTK/QT apps
That's not surprising: Gtk and Qt make horrendously poor use of the X protocol, memory, and resources. Performance problems people claim to experience with Gnome and KDE are due to the toolkits, not X11.
Of course, machines have become so fast that even Gtk's and Qt's inefficient use of X11 doesn't make any significant difference over modern networks and on modern machines.
The problem with only running on Sun Java and its derivatives is that Sun can break the system or supporting your platform at any time--you have no guarantee that you can use your OpenExchange server next year or two years from now.
Sun might, for example, decide that the only Linux they are going to support from now on is going to be their own version and they can refuse to license Java to anybody who wants to port it to any other version. Or Sun might simply screw up technically and break things (arguably, Sun Java is already pretty broken on many Linux systems).
Bluetooth has become commoditized; it's in the hands of low-cost chip manufacturers. That makes it uninteresting for a company like Ericsson and they are better off just buying whatever BT technology they need cheaper from elsewhere. If anything, that's probably a sign of maturity of the technology.
Does OpenExchange run on any open source Java implementation (gcj, Kaffe, etc.)?
If not, you have an open source project running on a closed-source runtime only--less than ideal.
Yes, compiling stuff for Windows is a lot of work and I see nothing intrinsically wrong with charging for the Windows version of an program that is open source on Linux.
But, sorry, if he uses other people's GPL'ed source code, he can't do that retroactively. Those are not the terms under which people contributed code to XChat, and changing the license after the fact without consent from contributors is a violation of trust. Such behavior is bad for the entire open source movement.
If you want to do any kind of dual-license work, you have to make sure that you don't put other people's code into your code under the GPL.
The solution? If there is an old version of XChat to which he holds sole copyright, he can start with that. Otherwise, he has to start from scratch.
It's not right: you shouldn't violate the terms of the GPL and promise to fix things when people complain. Maybe he can get away with it because he's too small to bother with, but think about what would happen if that became an accepted way of dealing with GPL'ed code: what if Microsoft or Sun did this? What about SCO?
Slashdot Mirror
It seems to be based on DXPC with more aggressive caching and some other improvements (e.g., it sends images in compressed form, breaks images up, and sends them at lower priority than window manager and other messages). Their mission statement says that it should work with any server and any client. It can also encapsulate RDP and RFB (VNC).
The biggest problem with remote access using X11 in the past hasn't been performance, it has been the difficulties of disconnecting/reconnecting applications. Originally, this had been envisioned as an integral part of using X11, but it was the applications that were responsible for supporting it and they never did. Eventually, we got tools like "xmove", but they were too cumbersome for general use. VNC succeeded so well probably not because of its compression (which is decent; in particular, it works with ill-behaved X11 apps like KDE and Gnome desktop apps), but because it made disconnecting and reconnecting sessions so easy.
Network transparent window systems have been in widespread use since the 1980's. RDP and Citrix are the typical "me-too" products in the Windows world, years late and not quite as good (but probably good enough to get the job done). Note that remote desktops are not necessarily aimed at dial-up. For example, X11 was not designed to use the smallest amount of bandwidth, it was designed for a LAN environment and still is far better than either RDP or Citrix on a LAN. Raw X11 is not the best choice for dial-up, but in combination with something like DXPC or NX, it is good there, too. And for the ultimate in thin clients, VNC is a great choice; VNC represents a completely different tradeoff in design parameters for remote displays.
Evas-based apps are at least 10 times more responsive than GTK/QT apps That's not surprising: Gtk and Qt make horrendously poor use of the X protocol, memory, and resources. Performance problems people claim to experience with Gnome and KDE are due to the toolkits, not X11. Of course, machines have become so fast that even Gtk's and Qt's inefficient use of X11 doesn't make any significant difference over modern networks and on modern machines.
The problem with only running on Sun Java and its derivatives is that Sun can break the system or supporting your platform at any time--you have no guarantee that you can use your OpenExchange server next year or two years from now.
Sun might, for example, decide that the only Linux they are going to support from now on is going to be their own version and they can refuse to license Java to anybody who wants to port it to any other version. Or Sun might simply screw up technically and break things (arguably, Sun Java is already pretty broken on many Linux systems).
Bluetooth has become commoditized; it's in the hands of low-cost chip manufacturers. That makes it uninteresting for a company like Ericsson and they are better off just buying whatever BT technology they need cheaper from elsewhere. If anything, that's probably a sign of maturity of the technology.
Does OpenExchange run on any open source Java implementation (gcj, Kaffe, etc.)? If not, you have an open source project running on a closed-source runtime only--less than ideal.
Yes, compiling stuff for Windows is a lot of work and I see nothing intrinsically wrong with charging for the Windows version of an program that is open source on Linux. But, sorry, if he uses other people's GPL'ed source code, he can't do that retroactively. Those are not the terms under which people contributed code to XChat, and changing the license after the fact without consent from contributors is a violation of trust. Such behavior is bad for the entire open source movement. If you want to do any kind of dual-license work, you have to make sure that you don't put other people's code into your code under the GPL. The solution? If there is an old version of XChat to which he holds sole copyright, he can start with that. Otherwise, he has to start from scratch.
It's not right: you shouldn't violate the terms of the GPL and promise to fix things when people complain. Maybe he can get away with it because he's too small to bother with, but think about what would happen if that became an accepted way of dealing with GPL'ed code: what if Microsoft or Sun did this? What about SCO?