June 2009 – Rodrigo Moya

Mapping Gran Canaria (call for help)

For all of you attending Gran Canaria Desktop Summit next week and with fancy gadgets like Nokia’s N800/N810, cell phones with GPS, etc, please take the opportunity for helping out the OpenStreetMap project.

How? Very easy, just make sure you set up your gadget to save tracks and have it recording your itineraries whenever you move around the city/island (no need to record your walks around the conference center 😀 ). With so many people with gadgets around the city for the week, I think we can improve the current situation (not bad, but lots of room for improvement if you compare it with the Google Maps version).

To save the tracks correctly, make sure to search for your device at http://wiki.openstreetmap.org/, and follow the instructions on how to set it up for good recording of tracks. The most important thing is to setup a good interval (I use every 10 meters or every second, whatever comes first). If you use a very long interval of saving track points, the tracklog would be mostly useless. Also, if you want to do more than just saving tracks, have a look at the map making techniques page. But please, just saving the tracks is enough for helping, so there’s no excuse if you have a gadget with GPS.

And then, when you have the tracks, just send them to me, if you don’t want to bother anymore, or, if you want to bother more, join the project and help editing the map.

CouchDB contacts in Evolution

Continuing with my CouchDB on the desktop series, here’s the 1st screenshot:

It’s Evolution addressbook components showing contacts from a CouchDB database. As stated in previous posts, all contacts in that database would be automatically replicated to a remote CouchDB instance, so, for instance, you could just see and edit/delete/whatever them from a web interface, and the changes would show up in Evolution.

Code is in GNOME git, under couchdb-glib and evolution-couchdb modules.

couchdb-glib 0.1

As the first step on CouchDB desktop integration, here’s version 0.1 of couchdb-glib, a GLib-based API to talk to CouchDB.

This initial version only allows reading and does all operations synchronously (not a problem in most cases, since the communication is done to the local CouchDB instance, which is quite quick, at least from what my tests show so far). Next releases will have all the missing functionality.

And, well, no screenshots to show, so here’s some example code for you to enjoy.

Source code is in GNOME GIT, under couchdb-glib module.

Desktop data/settings replication

In the last UDS, there were some talks about UbuntuOne, the technologies it uses, and how it could be well integrated into the Desktop. Also, there were discussions about how it could be integrated painlessly into upstream projects. So, here’s an idea on how this could be done.

First, it must be said that the easiest (and quickest) way of achieving UbuntuOne integration in Ubuntu would be to just patch/extend applications so that they supported accessing the UbuntuOne server, and have Ubuntu packages use that as default for users with UbuntuOne accounts. That would make most Ubuntu users happy, but it would not benefit at all users of other distributions, and worst, the upstream projects.

Now, if we look at the technologies being used in UbuntuOne, there is one awesome thing, called CouchDB, a project supported by the Apache Foundation, which provides databases (of JSON documents) that can be replicated (and 2-way synchonized) to other hosts. So, what if we had Linux Desktop applications use this for storage of files and settings?

couchdb-in-the-desktop

Well, what would happen is that we’d gain data / settings replication and synchronization for free. And also, if we could come up with standard formats / locations for common information (accounts, notes, mails, calendars, etc, etc), we’d also gain a shared storage for all applications to use, solving the problem of incompatible formats / locations used by similar free software applications.

And other advantages:

CouchDB knows already how to deal with conflicts, as this is included in the automatic replication / syncing features it provides.
While normal documents in CouchDB are JSON, you can attach any kind of file to any JSON document (even to empty JSON documents), so any kind of files can be stored. Also, it allows users to create as many databases as needed, so storage for different needs can be easily separated.
CouchDB provides a sort of revision history, so it could be used for nice stuff like Zeitgeist.
This, not being an Ubuntu-only solution, could benefit every Linux Desktop user.
UbuntuOne would be a service built on top of this that users can subscribe to. But others could just setup a CouchDB server on their home / company network and use that by just pointing their local CouchDB to their remote CouchDB replication server.

To continue my investigations/playing on this, I’m going to try writing a gvfs backend to manage files in the CouchDB instances. Once that’s done, applications could start just writing their files to couchdb://… URIs instead of file://… ones and enter the replication/synchronization world with just a single change. Next, a GConf/d-conf backend could be added for replicating/sync’ing settings, and so on.