Jetlag sucks, but time on aircraft is OK

I'm writing this on the flight from Tokyo to Sydney, with intent to publish later. Earlier today I flew the Frankfurt to Tokyo legs, so anything in this blog needs to be understood in the context of some potential jet-lag :-(

I did a bit of train journeying around Germany after aKademy (including a trip into Erlangen for Linux Kongress), and one of the articles I caught up on (in IEEE Computer magazine) was on Internet Suspend / Resume (see http://info.pittsburgh.intel-research.net/project/isr/). It is an interesting idea - they basically envisage a thick-client model, running on a virtual machine (VMWare in their tests) which can suspend. The suspend state then gets shipped over a network connection to another machine where it can be "resumed". The research work is in how to make it perform with acceptable performance over a slow network connection, and how to provide security when running the virtual machine on a potentially untrusted machine. Suffice to say that the performance problem is a lot easier than the security one :-). The advantage of the virtualisation approach (over the thin client approach of VNC or NX) is that it still works if the link isn't especially reliable or has lousy latency. Of course, it only works if the machines are running compatible virtual machine technology too, which isn't so likely in a pervasive computing future. That got me thinking about whether KDE could be adapted handle a suspend / resume case using session management. I'm thinking about a case where KWord can be suspended on one machine, and resumed on another machine (with different architecture, potentially even a different version of KDE) with the same file open, cursor in the same place, same dialogs open. Of course you need a shared filesystem (perhaps a USB key, perhaps NFS4), and there might be a lot of difficult cases, but it might be a lot better than having to network around a huge binary blob of suspend state that only works on some machines.

On NX, I see that kdenonbeta now has knx - an NX client for KDE. It might be nice if it just became part of KRDC in the mature state, and we supported SLP discovery for remote desktops. Of course knx refuses to buld for me using a top level kdenonbeta build - perhaps I need to try building it using KDevelop.

In addition to NX, it would be great if we could reduce the amount of X round-trip calls that Qt and KDE cause, since that would improve everyone's performance over remote sessions. Something like a round-trip-grind application could be very useful, so we can see which widgets / constructs are causing all the delays.

The other thing that is starting to annoy me is the poor PDF support we have in KDE right now. Between KPDF and KGhostview we have OK rendering, but anything beyond that (eg to cut-n-paste a paragraph) is woeful. There are a couple of hidden gems (including a PDF import filter for KWord), but nothing that even as good as Acrobat Reader, let alone a full Acrobat type capability. I'm tending to think that the "abrogate responsibility to another app" approach is a dead end. We have to parse the PDFs, and render them glyph-by-glyph ourselves. I'm optimistic that between the work that is being done in Qt4, and the KCanvas stuff that is being worked up in kdenonbeta, we can do much better.

Of course, I'm a long way away from doing any of those things, in both time and skills. Instead, I've been slowly working on a new tutorial (on kimgio plugins), and putting a fair bit of time into QCA. The QCA changes include new hashes (SHA-0, MD2, MD4 and RIPEMD160), more testing of the existing hashes (SHA-1 and MD5, plus tests for the unimplemented SHA-256), a new capability to do password-based key derivation (per RFC2898 / PKCS#5), and some partial API documentation. Hopefully I can get all that merged soon after I get back to some better connectivity.