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.
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.
Originally I wanted to keep out of the WTC-related discussions here because I still consider Advogato a OpenSource-related site... but yesterday they showed something in a german tv magazine that I have to tell the world about.
Remember the CNN pictures of the palestinian people
celebrating? German magazine "panorama" showed the
complete shot. There you can see that the life over there
went on as usual, only a few children celebrating because
a guy in a white t-shirt motivates them to do so. It also
shows that the old woman who celebrates does so because
they offered her cake, and she later denied that she did
it because of the WTC attack.
You can watch the clip in Real format here. It's a 10 minute movie in german, so you have been warned. You can find the CNN/palestinian part at 7:40.
config fs: I'm planning to abandon my proc fs
changes in a future version and instead write new
filesystem based on the proc fs code. Proc FS is a mess.
While most of the files
in /proc are quite convenient to read for human readers
they are almost unusuable for software. The problem is not
that parsing would be so difficult but that it is
impossible to add new fields once you have defined a text
format without breaking all software that reads it. Binary
files suffer from the same compatibility problems. A few
months ago several people convinced me on LKML to go the
"one-value-per-file" way for devreg, and the new
filesystem will enforce this even more than my proc fs
extensions. Every file will be strictly typed (string,
enum), dynamic directories will be possible, the type of a
can be retrieved using ioctls, and unlike my current proc
changes writing will be supported, too.
The more interesting part of the plan is that I want to support both persistent and non-persistent files. So there will be some daemon waiting, similar to devfsd, for files that have been flagged as persistent and will then store their new values when they have been changed. On initialization of a file the daemon will fill it with a previously stored value. Dynamic directories can have keys that can be used to find the correct one. I'm currently calling this concept config fs. Beside the replacement of proc fs for everything but processes it can be used for the configuration of the kernel and drivers. The current way of configuration definitely sucks, module options are a bad idea for most purposes because you cannot change them at runtime and they are not very useful if your driver handles several devices at the same time. They can only be used for the driver's global configuration, but not for the configuration of driver instances. IMHO module options should disappear for anything but boot-time configuration. The only frightening thing about the config fs idea is how close it is to Win2k's registry. It's a little bit less arcane because you can access it as a filesystem, but beside that there are only few differences between them. It could even make sense to use it for the general configuration of system software. bah...
I just wanted to point On2's VP3 codec that has been released in source form yesterday because it did not get as much press as it deserved, IMHO. VP3 is a very good codec with MPEG4-like quality, even if it is not their latest version (VP4). The license is a MPL with a compatibility clause: you are not allowed to take the code or use their patents to build something, that does not (also) encode or decode VP3 streams. While not perfect, it should be good enough to make me happy. It is at least better than the MPEG codecs that are poisened with patents. The source code has not been ported to Linux/Unix yet though, they just released the source for their Quicktime and VfW codecs.
I'm currently extending the device registry with a registry for drivers. It started as a simple idea to solve the problem of displaying several drivers that handle a single physical device. This is quite complicated as I use one-value per /proc file, so a list of values means creating a dynamic directory for enumerating them. I thought of creating a directory per driver and linking from them to the devices instead, which turned out as being a great idea. This does not only allow me to make more information about the drivers available, but moving the devfs node descriptors to the drivers solved some problems with finding the right node of unusual devices that have, for example, several nodes with the same interface. Even more important, I can now add device node ids that can be persistent identifiers of a physical device's devfs node (or major/minor number). This will make libdevreg much easier to use: if you want to find a device node just use its id as an argument to the find function. But even better, I now have an easy solution for having stable minor numbers in the kernel. Just fill a table (with the help of a /sbin/hotplug-style user space program) that maps device node ids on minor numbers. As a timeframe, I hope to have a version of devreg without the stable minor number thing ready in two or three weeks.
I am also writing on a system similar to the minor number thing but for major numbers with the major name instead of the device node id. It will hopefully be ready at the same time. This would solve Linus' decision of not allowing any new major numbers as it moves the major number location from the central register to the user or his distribution. I haven't seen any other patch doing this, which quite surprises me. However, I need this code for the device node id / minor number mapping.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!