One of the things that I would like to have in KDE 3.2 is better and easier file sharing. Right now, KDE's file sharing mechanism is pretty limited. Basically it allows you to export a directory via NFS and SMB, but both protocols (or at least their current implementations) are not ideal for a desktop. Nor is LISA, KDE's current network browsing mechanism.
My requirements for desktop file sharing are:
I think that I have found a very good and simple solution for this: fish. It fulfills every single requirement except the browsing ones. For browsing, I plan to use a very simple (KDE-independent) daemon that keeps SLP registrations open. It can run with user permissions, but should be running all the time. This, the required slp daemon and the performance are the disadvantages of this solution.
My webservices implementation reached a dead point at the weekend. This usually happens when I am stuck in boring and unpleasant work. The WSDL implementation is the culprit, implementing this is much uglier that I expected. I guess I will spend the next few days on the file sharing stuff and syncing the GStreamer bindings with the new release...
Wow, almost 6 months since my last entry. I produced a lot of code since then and have even more stuff in the pipeline. I'll try to summarize what I was doing in the last months...
KDE Desktop Sharing
Well, it's done - at least for KDE 3.1. All user-visible references to the old name 'krfb' have been removed. Now the official name is 'desktop sharing'. I never liked the habit of giving strange names to applications anyway. Who knows what a 'Noatun' or a 'Nautilus' is? I also added a few new features: if you configure it to accept connections without prior invitation, it will announce its presence via SLP. That allows an administrator to search for users on the network without knowing the name of their computer. I also enhanced the protocol to transmit the position of the cursor. This can reduce the traffic a little bit, and makes it possible to have a larger or more conspicuous cursor on the client.
So far the application is optimized for a single use case: an inexperienced user wants to invite a friend or administrator to help her. Unfortunately this is not, what most of the people, who downloaded the software or tested the KDE betas, wanted. Most of them seem to have several computers and want to control them from a single machine. Desktop Sharing is not a good solution for this, and never will be, because the performance is quite bad and the user must be logged in all the time. Using the regular VNC server is a better idea, but most people seem to have problems configuring it. See below for a X11-based solution for that problem. Another use case that is not optimized yet is an administrator who wants to connect directly to a group of workstations. Because of VNC's very limited authentication mechanisms the only way to authenticate is against a single master password that is stored locally. This is, well, sub-optimal if you have a few dozens or even hundreds of workstations. I plan to solve this problems by extending the protocol with Kerberos support.
Remote Desktop Connection (krdc)
Yes, I finally managed to produce a VNC client, and it's in KDE 3.1. I took the TightVNC unix client and rewrote it to run in two threads, controlled by a Qt GUI thread. I also added a few GUI goodies, like a much nicer fullscreen mode and a 'scaled' mode that scales the content to fit the window. For Desktop Sharing it supports user browsing via SLP and the 'soft cursor' extension. Planned features for 3.2 are Kerberos authentication for Desktop Sharing, and possibly a ssh/X11 mode. Instead of using VNC, it should log in using ssh into a remote computer and start a regular X11 session. krdc will then run an embedded xnest locally. It will look like VNC and be as easy to use, but with the more bandwidth-friendly gzipped-X11. This solution has a lot of advantages, you only need to have ssh running on the remote computer and you have the full ssh authentication and encryption options. It should be the ideal solution for the "user with several workstations" use case (unless the user uses a non-KDE environment on the client).
I had a few weeks of vacation in august and wrote KDE/Qt wrappers for GStreamer. I am quite impressed by GStreamer's architecture and I think it will be a worthy contender for KDE 4.0's multimedia framework. I decided not to work on GStreamer projects in the next few month though. I have a lot of other things that I want to do, and Gst still has a number of rough spots that I experienced while writing a few examples for the binding. Instead of losing time while working around them, it's better to wait a little bit for GStreamer to mature...
I have always been a friend of JavaDocs, kdoc and similar API documentation systems. The quality of documentation is an important point for me when I decide whether I use a system or not. For example, Python is a nice programming language, but there is no good API documentation available. The official library reference is just a document, which makes it quite useless for me. There is no standard for Python API documentation (so every library is documented in a different way), it is not cross-linked with other documentation, and a document makes it too hard to find a function or class.
KDE's API documentation is pretty mediocre. Some classes are really well-documented, but others are incomplete or not documented at all. So I started adding missing documentation. So far I am through with the kdecore and dcop packages, every single class, function and argument is documented now. It is not as good as I would like, for example it needs more examples, but it is a beginning. Right now I am working on kio, and I hope to finish kfile and kdeui for 3.2 as well. Documenting classes is like playing Tetris, really adicitive, you should try it :)
During the hard feature freeze for KDE 3.1 I started writing a WebServices package. Originally I only wanted to implement sending SOAP messages, but then the new DCOPRef syntax inspired me and I wanted RPC as well. It got bigger and bigger, now I have a XML-Pull-Parser API, a WSDL implementation and soon Soap RPC. I hope to release it when the feature freeze is over.
A few points on the SOAP discussion:
SOAP itself is not dangerous, and the code that handles SOAP requests is not more dangerous than any CGI script. The input and output just have a more restricted form which should make it rather more secure.
krfb/krdc: After the failure of the windows vncviewer port attempt I tried to port the UNIX vncviewer, with much more success. The thing, now called 'KDE Remote Desktop Connection' or krdc, is not very far from being complete. I am currently working on the fullscreen mode...
A few weeks ago, on the same evening I wanted to start improving keystone somebody appeared on kde-devel and said that he implemented a QT-based VNC client and wants to port it to KDE. So I gave up the keystone idea, even though I haven't seen the new client yet and I am not sure whether it will actually see the light of day.
Progress on krfb 0.7 is ok, the KControl module is working, the kded module (kinetd) looks good (but wasnt actually tested). Now all that I need is the invitation feature and make sure that everything works. I hope to get 0.7 out this month. After 0.7 a loose code freeze will start, and I only plan to do bugfixes, maybe add some minor features and, of course, documentation and i18n stuff.
Keep up with the latest Advogato features by reading the Advogato status blog.