Archive for October, 2006

Calendar

I’m about to disappear for a while to get married, so there most likely won’t be posts here for a while.

On another subject entirely… last year I realized that there doesn’t seem to be a very easy way to get an overview of all the free software conferences going on worldwide. The last week or so I’ve spent some time digging up links and dates and whatnot and putting them into a google calendar. This isn’t ready to be unveiled but I thought I’d put the idea out there. I’m not sure exactly how I want to deploy it yet — plain google calendar? A web site with extra features? Your idea here — what would be most useful?

Also once it is up I’d appreciate info on what I’ve missed. I’ll probably set up a new mail alias for that.

More on synchronization

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.

Gnome 3.0 links

I’ve been reading about Gnome 3.0 lately and I’ve run across some interesting links.

I thought the lazuli mockups looked quite nice. One problem I see in Gnome is that many programs feel quite heavy — e.g., I use evolution only for its calendar, and it seems like an awful lot of UI for something that is conceptually much less important. Programs should have a UI presence about equal to their general importance in my daily life; I only “calendar” occasionally. So, my calendar ought to be invisible most of the time (evo does this well), and quite minimal when I do pull it up (evo fails here). The lazuli screenshots seem to capture this idea pretty well.

This site is sort of a bumptop-y thing written in flash. It is pretty fun to play with. If you click on one link in this post, click on this one.

Gimmie looks pretty cool.

I’m including a link to the Mozilla desktop only because it exists. Mostly I think focusing on the implementation technology is a mistake. Users don’t care — I know I sure don’t. Working on multiple platforms is nice, too, and I can see how that would be useful, but doesn’t fit into my reality.

On the calendaring front, wuja looks like an interesting idea. I’m not a huge fan of web-only software; wuja bridges the gap in a nice way.

Recent Hacking

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).