GObject for language-independent APIs
mikehearn proposed using GObject as a way to share libraries between different languages and platforms. I think there are two problems with GObjects that are much bigger than those that he mentioned:

1. GObject does not allow to browse the methods of a class at runtime and invoke them (what Java calls introspection and MS Automation). This is needed for making scripting/dynamic languages first-class citizens, as it is not realistic to expect that wrappers for a large set of libraries and languages can be kept up to date. Any viable contender for cross-language APIs needs to offer introspection
2. GList, gchar strings and friends are a problem, because the performance cost of converting them to the high-level platform's types are high. gchar strings would need to be UTF8-en/decoded for every call if the platform uses unicode. GLists would have to be converted into the platform's native list representation, which is a o(n) operation. The only clean solution is that every type except numbers must be represented by a GObject as well.

BitTorrent
I don't understand the fuss about BitTorrent and similar systems. In the end I pay with my own bandwidth. For each file that I download I will have to upload at least the same amount of data, otherwise the system can't work. And here comes the problem: for me, as a regular dial-up or DSL user, bandwidth is much more expensive than for someone who hosts the file on a server. At T-Online, Germany's largest provider, I pay 15,90 EUR (ca. $15) per GB. On the other hand, when I co-locate a server, I don't pay more than 5 EUR per Gigabyte (at fileburst.com the rate is <$1/GB). And routing the traffic through dial-up, cable and DSL connections instead of dedicated servers is complete nonsense, technically seen, more expensive for the network infrastructure as a whole and almost always slower. The only reason why people do this is because a) they have flat rates and b) there is no easy way for micropayments. I think sites that require the user to pay for bandwidth are a much better way to solve the problems for content creators. Flat rates will soon be a thing of the past when things like BitTorrent get more popular, and even if the processing overhead for micropayments is %80 the bandwidth from a dedicated host is still cheaper than the bandwidth cost for many dial-up/DSL users.

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.