Novell Hack Week #2

I decided to continue on with my hack week idea from last year.

I spent the better part of a day getting the devel environment set up (compiling and setting up myth from HEAD, setting up the latest compiz-fusion from the build service, and gathering some test HD videos for myth) only to find out that it looks like it's been fixed already! We'll have to wait until the next major release of myth, but it's in there. Moving on.

The next item was a leftover idea that had been kicking around from the Tomboy hack night last December.

For that event I wrote a little python script that rapidly created notes over the Tomboy dbus interface. I gathered some data about how Tomboy performs with a large number of notes. The main findings were:

1. Start up time was pretty dismal with a large number of notes (even 1000, which isn't that inconceivable)
   
2. Note creation time steadily increased as the number of notes increased
3. The time it took to delete notes was much longer than desired when you had a large number of notes
4. Tomboy performed quite well during typical use cases, even with a large number of notes
   

Hence my Hack Week #2 project: add an sqlite backend to Tomboy to help address some of the performance issues in Tomboy.

Boyd had mentioned that Everaldo and crew had done an sqlite backend for the maemo Tomboy port. My first objective was to port that code from the 0.7.x codebase to trunk (0.9.x?)

It turns out the maemo port was done mainly to work around a bug in Mono running on the n800. The maemo sqlite port allowed a mechanism for storing multiple notes inside one file in order to work around the aforementioned bug. That alone wouldn't solve the above issues. (In fact, this sqlite backend was significantly slower than the file backend unless delayed writes were enabled for the sqlite db. With delayed writes, they performed roughly the same.)

I spent the rest of hack week getting introduced to git and git-svn (which really rock!), getting my feet wet with C#, reading Tomboy source code, investigating Linq, and writing the C# code to do the db schema creation and schema upgrades. The main conclusive points of interest are:

1. To utilize the sql db, queries are needed to pull only the notes into memory that are of interest (otherwise, with all notes in memory, I'm guessing that's a main reason as to why the previous list of shortcomings occur, especially startup time)
2. Find out if the current note buffering scheme is needed during note editing. If not, the code could be simplified by persisting changes straight to the db.
3. We'll likely need an interface to transparently search and interact with notes in memory or from the db (meaning, I'm guessing the findings from #2 may be futile)
   
4. Provide note migration from xml to db
   

I seem to get mixed reactions from those who hear about a change like this. Some say, "Yay, with 200 notes, Tomboy is slow with some things!". Others, "Tomboy will likely move to using a db anyway." And, "With so much work and so little possible gain, why bother?" And lastly, "Eww, no db! Then I won't be able to ssh into my home/work computer and poke at the .xml note files!"

To alleviate at least the last point, Andrew wrote a sweet command line util: Tomboy Remote. (Because you shouldn't be poking at a program's internal data anyways!) Update: Source download.

In conclusion, there's quite a bit of work remaining. The main benefits of this week were that I got some C# exposure (finally!), experienced a great use case for decentralized scms, and got more familiar with the Tomboy codebase. More for next time!

On another hack week semi-related note, I just upgraded my home system. (I got an intel mb, Core 2 Duo (E6550), 4 GB of ram, and an nvidia 6200le card for $300 after rebates. Thanks Joel and Steve!) Anyway, the onboard sound only has one audio port. Luckily Herbert was kind enough to add my last years hack week PulseAudio patch to the Packman rpms. Great timing!