I started a draft implementation of my identity synchronization idea. In the course of doing this I ran across a minor problem.My initial idea was to keep things very simple: a shared resource would be a collection of bits, and the users of the API would handle all aspects of interpretation. The library would handle bookkeeping details but would defer conflict resolution to the caller — handing back two versions of a file (three-way merge is a possibility, too, but I’m not convinced it is worth the effort) and having the caller respond with a merged version.

Now suppose you log in on your laptop and make some changes while disconnected. When you subsequently reconnect, the ideal would be for all the identity data to automatically resynchronize with the server. This seems like the most useful thing to do — I don’t want to have to actually restart RSSOwl for my saved blog-reading sessions to be available to my other machines.

Unfortunately this throws a wrench into the naive approach outlined above. If the synchronized data is uninterpreted bytes, then any conflict will mess up the idea of generic synchronization without running a particular application to handle a merge.

One way to fix this would be to mandate a file format so that the merge code can be generic. I’m not very fond of this. The other, and I think superior, plan would be to handle conflicts monotone-style: let all commits succeed, and handle merging on demand. In this model we can upload a file (with some ancestry info); when downloading updated files from the server we would simply download all available “head” files and the application would perform multiple merges.

This means having a smart server, but I think that was inevitable anyhow. (Probably Nathaniel is on target, as usual, and I should be reusing monotone’s code for this…)

Another little problem that came up is keyring management. In particular, the gnome keyring will be needed to decrypt data downloaded from the server. But, we want to store the keyring itself as a shared resource. I think the only answer here is a special API used only by gnome-keyring that lets us skip over the download step the first time the keyring file is needed.

Finally, there is a completely different design available. We could use a file-based service like monotone, check things in, and then provide merge utilities for each different file type. One way I don’t like this is that I suspect that current programs don’t differentiate between the different types of stored data; changing the programs themselves ensures a clean separation of identity-related data and transient data. At least for the time being I’m sticking with my first approach.

Lately I’ve been doing some random Gnome hacking. I’ve been a bit bored with what I’ve been working on recently (SRPM hacking — I hate this stuff) so I’ve cast around a bit for other things to do.

At first I was playing with frysk, but I promised myself that I would be a dilettante and hack only the fun bits. Unfortunately this means I’m now stuck waiting for other folks to write some important infrastructure, and also to fix a few mildly contentious bugs. (The bugs would be fun, but I’m also not interested in navigating the controversies in my spare time…)

So, I inconsistently turned to hacking on gnome-session — something both un-fun and contentious. I’m not always sure what I’m up to…

I’d forgotten exactly how awful XSMP is. It pretends to be policy-free, but when you look deeper you see that it makes many implicit assumptions about how things will actually work. It also uses the egregiously nasty ICE. And, of course, gnome-session’s implementation is no great joy, either, which is more than a little my fault.

Anyway, I fixed a number of problems and now I’m waiting for patch review.

Gnome hacking has gotten better since the bad old days. The documentation (glib in particular) has improved, for one thing. The newer APIs are also more well thought out.

I looked a bit more into a minimal implementation of my state-sharing idea. Gnome seems to already have most of the bits I’ll need: I can lift some encryption code from gnome-keyring, and gnome-vfs allows easy access to remote sites (the latter isn’t perfect for my purposes but will do for a proof of concept).