![[lang]](/images/eye.png)
desktopcouch on Fedora |
2009-11-22
|
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.
- 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 ?
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.
Wow! Nice work, that man! I owe you a beer.
Now, for answers to questions.
1. You shouldn’t use the username and password. Access to desktopcouch is meant to be through OAuth-authenticated requests. I wouldn’t have the username/password in there at all, except that web browsers don’t do OAuth and so there’s no other way to get at Futon other than by using basic auth. The desktopcouch.records module hides away all the OAuth details so you don’t need to think about it.
2. Pairing with another user on the same machine…there’s a variable, show_local, in the pairing code, which is set to False. This is so that when you say “make me available for pairing”, your own desktopcouch doesn’t show up in the list of “desktopcouches available for pairing”! It does this by excluding stuff on localhost, which will also exclude desktopcouches run by another user on localhost. You can change the value of that var to True to make it detect even local things (and then you can also test pairing by pairing with yourself, as well as pairing with another user on the same machine).
3. desktopcouch.records does, basically, two things.
a. it abstracts away details that you should not have to care too much about (OAuth and port discovery)
b. it enforces the record format.
Now, all that the record format requires is the following:
i. Every record has a record_type entry
I think both of those things are important. One of the goals for desktopcouch is to enable applications to collaborate on data storage. So if I store my Evolution contacts in desktopcouch (as evolution-couchdb does), it sets the record_type to be a string of a URL pointing at a schema for that record format. So if Thunderbird also starts storing contacts, they can collaborate on the format. I’d really like to not lose this property. Even if you’re only storing data for your specific application, storing it in a lightly-documented schema means that other people can find out about the data format later. We in no way enforce an actual schema (this is not XML!), nor is it enforced that the record_type is actually a URL or that there is documentation at that URL, but it’s a really good convention. If you’re finding that desktopcouch.records is doing things that you really don’t like, please come talk to me about it, because it’s a light layer over the top of python-couchdb, and the little things it enforces make sense for the larger-scale health of the platform, if you see what I mean.
Ping me on irc (#ubuntuone on freenode) for a more detailed chat about this?
I am incredibly pleased about a version of DC being available on Fedora, I have to say :)
Comment by Stuart Langridge — 2009-11-23 @ 01:26
Stuart didn’t mention it, but I think ALL databases get synchronized when you pair. We are just using the couchdb replication stuff, which I think defaults to replicating all of the dbs. However, as Stuart did mention, it is a good idea to go through desktopcouch and define a record_type to use.
Comment by Rodney Dawes — 2009-11-23 @ 04:49
Oops, yes, I didn’t answer question 3. Replication doesn’t care about what’s in a database, and syncing to Ubuntu One uses replication, so whatever you have in desktopcouch will be synced if you’ve paired with Ubuntu One (starting up the Ubuntu One client applet creates this pairing for you).
Comment by Stuart Langridge — 2009-11-23 @ 08:50
Let me know where you get on this—the Gwibber devs have told me that they’ll eventually require desktopcouch in a future release.
Comment by Ian Weller — 2009-11-23 @ 23:34