Desktopcouch on Windows/Mac

One of the things that I’d really like to see is desktopcouch on Windows and the Mac, so that your data can be everywhere, on all your machines. Now, I don’t know enough about those platforms to actually do it, but I’d be happy to help anyone who was interested in making it happen; here are some thoughts on what’d be required, and do please chip in here with questions, or ask me or others on the #ubuntuone IRC channel on irc.freenode.net. Desktop Couch, for those of you who aren’t sure, is a personal CouchDB that your apps can store their data in. It’s secured for you alone, and it comes with a built-in replication setup, so two desktopcouches on the same network can exchange data. This means that if your applications store their data in desktopcouch — for example, Bindwood, our Firefox extension to store your bookmarks there — then all the machines on your network can exchange that data, meaning that adding a bookmark on one of your machines will automatically add it on the others, without you having to do anything, and without you having to sign up to some third-party service to make that happen. It’ll all work on your local network. (It can also work via a third-party service — Ubuntu One is such a service, and there could be others, as long as they deploy CouchDB in the cloud — so that machines on different networks can also exchange data.)

CouchDB

The first thing you need to have, to get a personal CouchDB, is CouchDB. I know the Mozilla Raindrop team have done some work getting CouchDB nice and robust and working on Windows, and I believe they have an installer. Working with that would be very cool indeed. (Indeed, it’s possible for Raindrop to use desktopcouch if you have it, so that might be an interesting test!)

On-demand startup and port numbers (or, what’s your D-Bus?)

Desktopcouch is started on demand, when the first application requires it, rather than running all the time even when you don’t need it. Because it is a personal CouchDB, and because there might be more than one user on the machine that you’re on, it can’t run on a specific port number; instead, you ask desktopcouch for its port number when you want it, and asking that question starts it up on a randomly-chosen port if it’s not already running. The way this is done on Ubuntu (and other Linuxes) is with D-Bus, which is a Linux-specific IPC mechanism. It’s possible to use D-Bus on other platforms, but a much better way would be to use your platform’s specific way of passing messages to a service and starting a service if it’s not already running. (This is one of the things I don’t know how to do on other platforms. Would Macs use launchd or something? Should a Windows service be running on startup? I don’t know.) Desktopcouch only uses D-Bus for these two things (“what’s your port number” and “start this service if it’s not already running”), so replacing those sections with a native way of doing that on Windows/Mac would be reasonably easy and make it fit in much better with the Right Way of doing things on that platform; these changes would need to be made both in desktopcouch itself, and in APIs (desktopcouch.records) that connect to desktopcouch.

Where are the keys? (or, no gnome-keyring on Windows)

Because desktopcouch is a personal CouchDB, access to it is secured by OAuth. When desktopcouch is first set up, it randomly generates a set of OAuth tokens, and these are stored in the Gnome keyring on Ubuntu. Obviously, it would be better to use the platform’s own way of storing authentication data; I believe the Mac has a “keychain”, and Windows surely has something similar. Again, this would need changing in desktopcouch itself (to store the keys in the right place), and in desktopcouch.records (to retrieve the keys from that place to use them).

And that’s it

With those changes in place, desktopcouch should run on another platform, meaning that you can exchange data between all your apps on all your machines. We’re already getting some sterling work done to see desktopcouch on other Linux distributions and on phones like the Nokia N900 (hooray for Thomas, among others!). I’d really like to see this happen on Windows and Mac too; are you interested in helping make it happen? Let me know, and I’ll give you all the help you need!

10 thoughts on “Desktopcouch on Windows/Mac

  1. Pete Goodall says:

    Looks like Windows has several equivalents to DBus, but maybe COM is the most appropriate (http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx). Thx for posting this Stuart!

  2. foxxtrot says:

    Unfortunately, I think Windows 7 is the first version of Windows with an equivalent to GNOME Keyring in the form of Credential Manager. Unfortunately, the service for Credential Manager, while included in every version of Windows 7, doesn’t appear to be started by default, which could be a problem.

  3. sil says:

    foxxtrot: ah, well, if there isn’t a system-wide service for credential storage on Windows then desktopcouch could happily implement its own; in the early days of desktopcouch we had apps parse the couchdb ini file for the tokens, and that’s abstracted away by the API (desktopcouch.records in this case), so that wouldn’t be too hard to continue with.

  4. Rodney Dawes says:

    There is a semi-useful keychain thing in Windows XP+ I believe. And python-keyring I believe handles this. All we really need to do is switch desktopcouch to using python-keyring instead of gnomekeyring, and should be good. This is of course assuming python-keyring provides the same level of API support as gnomekeyring does. The ACL and service typing features of gnomekeyring are quite awesome.

  5. sil says:

    dobey: yep, and thomasvs is looking at python-keyring as part of his N900 port, which is lovely :-)

  6. Pascal says:

    I would love to have a solution on Windows (for work) and Mac (for home). Today, I rely on DropBox to do this (a great system, by the way), but I would feel much better with an open source solution. I don’t like to rely on proprietary protocole made by a for-profit company to share my data over the web. Storing encrypted data on DropBox is only part of the solution…

  7. Manuel de la Pena says:

    From my point of view, if you want real integration with windows you will probably have to write a .Net API that provides the same functionality as is found in desktopcouch and probably you could relay in the WIF (Windows Identity Foundation) to deal with the auth (just an idea). Most application currently written for this platform are C# based and they are the ones that should be targeted (you can always make a .Net assembly be COM visible).

    Using C# will give another problem, httplib2 is not multi-threaded AFAIK which is a must in an environment like Windows. Windows prefers to be multi-threaded rather than multi processed. Certainly you could do a partial port (probably 100% close) of the initial code, or part of the code base using IronPython, but that from my point of view should not be an option since the DLR is more of a .Net 4.0 feature rather than a 3.5, on top of that, if you have a semi-wrapper in C# you might as well write it on Mono which then will allow C# applications to use desktopcouch from Linux (I’d love that).

    Another option would be to use the API that the guys of Raindrop have done to talk with desktopcouch an adapt their code to deal with desktopcouch and change the keyring to be the python-keyring, but yet again, if you want real integration with the platform you will have to make sue that multithreading and async methods are part of desktopcouch, and make it easy for .Net boys…

    If g***ps for contacts does not turn out to happen (my xmas homework) and you guys want, I can give ti a go (sig… please don’t make me, Windows at work and Windows at home :*( ).

  8. Mekk says:

    Whether python-keyring is suitable currently, or not, I would recommend using it and extending it if necessary instead of implementing specific solution. Many Python projects may benefit sooner or later…

  9. sil says:

    Mekk: indeed. that’s what’s being looked at.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>