Older blog entries for tjansen (starting at number 14)

File sharing

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:

• sharing a directory must not change any permission rules on the server (unless the user is authorized to make a directory available for everyone)
• in an unmanaged network, sharing a directory must not require any configuration beside marking the directory as shared
• it must be possible to browse shared directories on the network (with all available information)
• it must be possible to attach a description or a descriptive name to a shared directory
• it must be possible to access the shared directory from every computer, even in an unmanaged network, with a username+password account that is valid on the server
• in a managed network it must be possible to access all directories without additional login
• the browsing mechanism must scale in very large networks
• it should be possible to establish a 'trust relationship' between two computers (for example two computers in a home network), so the user does not have to log in every time
• the file transmission should be encrypted, at least optionally
• it should use an existing protocol and server, if possible

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.

SOAP+web services

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).

GStreamer

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...

Code documentation

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 :)

SOAP+web services

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.

SOAP

A few points on the SOAP discussion:

• SOAP itself does not mandate transmission over HTTP. You could, for example, use BEEP as a transport.
• SOAP over HTTP was definitely designed to get through firewalls and HTTP proxies. This is the reason why people use HTTP and not a superior transport like BEEP (that would allow communication from the server to the client without pulling). If it did not use HTTP all those web services would not work for many problems, it would require a huge change in the infrastructure. Basically everybody who can access the web only over a www proxy could not use those web services.
• If your problem with SOAP is that you can not prevent a user/client from using it, read my last entry - you can not effectively limit the user's communication anyway.
• if your problem with SOAP is tunneling the firewall on the server side: you dont want SOAP to run on port 80, use another port. If you dont want to use HTTP, you are free to use another protocol. You will lose a lot of users/customers, of course, because many of them wil not be able to use it.
• I also don't buy the 'build an abstraction layer around the interface' argument. Basically SOAP is the abstraction layer. If you write one yourself you write more new and unproven code and introduce more potential security leaks. And, of course, you will lose a lot of time that you can also spend on making your code more secure.
• If your problem with SOAP is that it makes it too easy for server developers to shoot themselves in the foot: if you really take a COM object and make it available via SOAP without a security audit then, well, it is your fault. But the technology is not bad only because it allows stupid people to do stupid things. If that was true Unix would be the worst of all operating systems...

SOAP and security
I cannot understand the 'SOAP and Security' discussion. Of course you can use SOAP with HTTP as transport to get through a firewall and it's stupid to make such a fuss about it. When you allow a system behind a firewall to communicate with arbitrary systems outside of the protected network, you can not limit its communication. SOAP just makes it easier for the average programmer to do this, but you can achieve the same thing with REST, emails or even DNS. A firewall may make it a little bit more inconvenient for a user to connect to the outside, for example you can prevent them from using Real Audio apps by blocking the appropriate ports. But if they really want to, they can - theoretically - stream the data over an DNS tunnel.
Beside monitoring, the only good reasons for a firewall are to

1. block incoming connections to some or maybe even all ports, in order to prevent access to systems and/or protocols that the admin does not want to expose (e.g. X11, NFS, printers).
2. in the case of application firewalls: make sure that no currupted data is sent, to exploit things like buffer overflows, and maybe to limit the capabilities of the protocol. For example an application firewall could prevent POST requests in HTML. This could be used to 'cripple' the server and turn off unused functionality that may be exploited otherwise. It's just another form of risc reduction.
3. Block outgoing connections to ports, in order make it inconvenient for users in the secure net to use certain apps. This is more about telling users what they are allowed than actually preventing it, unless you block all ports.
   

This is what you can expect from a firewall. What you can not expect is to prevent a protocol, that has been designed for transmitting documents and form data, from being used for other purposes.

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...

krfb: Started porting the windows vncviewer, but then decided against it. While it would certainly be possible and less work than the other alternatives it is more work than I had hoped. Porting with the full feature set would probably cost me a whole month (working in my spare time). So I scrapped it, for now, and will spend the rest of the weekend working on the krfb server.

krfb: A few days ago krfb has been moved into the kdenetwork package, so chances are good that it will appear in KDE 3.1. This makes a KDE client even more neccessary, but unfortunately I haven't heard anything from the QT-VNC guy. Right now I am considering to port the windows vncviewer directly to KDE. It doesn't look very difficult and should be easier than taking keystone and rewriting the vncviewer code to fit. But even if I would finish this I know that I will spend endless time maintaining this, which would hurt the other things that I have planed to do... I will see what I can get done this weekend..

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.

krfb: Finished porting to libvncserver, added KNotify support and somebody send me a patch with a DCOP interface that I have integrated, too. In other words: version 0.6 is out.
So now my next task is to add better encodings to keystone and maybe improve its GUI.

krfb: I was almost finished with porting the codecs to krfb and several improvements on the backend when somebody told me about libvncserver. So I scrapped the complete x0rfbserver backend and replaced it with libvncserver. As of today it is almost running, and I am glad that I can worry less about that stuff and can concentrate on other things. As soon as the next krfb version is out I plan to improve keystone so KDE gets an up-to-date vnc client.

KIO/WebDAV: My webdav patch is dead after I discovered that somebody else already wrote one, so I can focus on getting vnc/remote things right.

Many things happened since my last diary entry.. Patrick Mochel submitted his new Linux driver model, which was much more radical than my humble attempt at collecting device data only, and it got into the 2.5 kernel. This made my Device Registry patch pretty obsolete which isn't too bad because I did not want to work on kernel stuff forever.

So I moved on to work on further items of my virtual TODO list to make KDE/Linux a more enjoyable desktop.

By accident I found x0rfbserver, a VNC implementation that shares your X11 session instead of creating a new one. Remote desktop administration was on my TODO list, so I ported it to KDE and created KRfb. It was also a nice little thing to get started with KDE development which I never did before. Two weeks later (we're now around christmas) the port was finished, but I did not want to release it before I got some response from x0rfbserver's author. So I started another small project: WebDAV support for kio_http. I added all the new commands, header fields and status code, but the biggest part, XML parsing of WebDAV responses is still missing. On January 2nd I was fed up waiting for x0rfbserver comments and released the first version officially. I got more reactions than I thought, especially from people who wanted TightVNC support and so I decided to add it. While looking at the RFB protocol implementation of x0rfbserver's rfblib I found many bugs that I had to fix. I also found out that the implementation of the codecs was quite bad (lower compression rates than possible), so I started the porting codecs from TightVNC's winvnc and replace the original ones as well (yes, I am porting from the Windows version, because it is in C++ and the Unix version in C). So far Hextile and RRE are running, I will probably skip CoRRE and start ZLib tomorrow. Then I only need TightVNC and can release KRfb 0.6, maybe even this week, and maybe I have time for the WebDAV stuff again.