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,
int, ulong,
enum), dynamic directories will be possible, the type of a
file
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.
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!