Time to unravel some tufts of the yak hair lying around from this weekend.

I wanted to work on making my GTD application (using CouchDB) a little more friendly.

I started out by learning GreaseMonkey so I could modify Trac pages to include a link converting the ticket into a thing in my application.

The basics of that were easy, but I need to learn a bunch more Javascript before it will actually work well. So, I switched to finally figuring out if desktopcouch might be a good solution for the general problem for users to set up a couchdb database.

desktopcouch’s tagline describes it nicely ‘A CouchDB for every desktop.’ From what I can tell, it has:

a way to automatically start a per-user couchdb instance

oauth enabled by default for it, so only you can get to it

some gnomekeyring integration

a pairing tool that makes it easy to pair with other desktopcouch instances on your network

a python module on top of python-couchdb that layers a ‘record’ concept over CouchDB documents using record_type and record_revision keys

some pre-defined record types for notes, contacts, and bookmarks

possible integration with the UbuntuOne service

At this point I don’t know how intertwined this record concept is with the rest of desktopcouch. As at the moment I want to use desktopcouch simply as a reliable way to get a secure, per-user, replicated couchdb database, I’d prefer to not deal with records at all at this point.

In the process of getting acquainted with desktopcouch and packaging it for Fedora, I ran into a few little niggles:

First off, bdist_rpm didn’t work for desktopcouch because of the man pages being compressed.

My first run failed. Furthermore, the unhandled exception left my $HOME/.local/share/desktopcouch in a half-done state; I ran it again, and it worked, but it didn’t generate a couchdb.html as it should have because of this.

Some rpmlint warnings

As for the package, if you’re on Fedora 11, just install tao-release for F-11 i386 then type ‘yum -y install desktopcouch’

After that, you can start it by asking it for what port is running:



dbus-send --session --dest=org.desktopcouch.CouchDB --print-reply --type=method_call / org.desktopcouch.CouchDB.getPort



If all goes well that should come back with a number.

You can now access your desktopcouch through Futon with:



firefox $HOME/.local/share/desktop-couch/couchdb.html



Let me know if this worked for you or not !

I have a separate post about packaging ubuntuone stuff, which was much more complicated – and I’m still not sure if I will be able to use it as an online server for my couchdb app.

Now, for some questions to you desktopcouch-savvy people out there:

Looking at the generated couchdb.html, I see that I can now access the user-specific couchdb with a generated username and password. If I want to push my GTD app to this couchdb, I can do so using this username and password. So, obvious questions: a) should I push with couchapp this way to get my app in desktopcouch ? b) is there a better way to get this username/password ? I assume desktopcouch does this in the python modules using gnome-keyring c) is it an intended mode of operation to be able to push my app into the user couchdb ? I am working on the web interface part served by couchdb and I want it to be one of the ways in which to access the data.

Is it possible to pair with a different user on the same machine ? I was on a laptop with no other linux computer around, so I was not able to test the pairing. I did set it up for a different user, but neither account seemed to see the other’s couchdb running. Will I be able to sync non-record databases to ubuntuone ? If not, what else could I do to have an online couchdb to sync between my various work machines ?

Time to unravel some tufts of the yak hair lying around from this weekend. I wanted to work on making my GTD application (using CouchDB) a little more friendly. I...