Ubuntu Wiki

Dev Week -- Hooking your app into your desktop CouchDB - aquarius -- Wed Sep 2nd, 2009

UTC

(02:03:55 PM) aquarius: Hi, all. Welcome to Stuart's House Of Desktop Couch Knowledge.
(02:04:15 PM) aquarius: I'm Stuart Langridge, and I hack on the desktopcouch project!
(02:04:18 PM) aquarius: Over the next hour I'm going to explain what desktopcouch is, how to use it, who else is using it, and some of the things you will find useful to know about the project.
(02:04:28 PM) aquarius: I'll talk for a section, and then stop for questions.
(02:04:35 PM) aquarius: Please feel free to ask questions in #ubuntu-classroom-chat, and I'll look at the end of each section to see which questions have been posted. Ask at any time; you don't have to wait until the end of a section.
(02:04:40 PM) aquarius: You should prefix your question in #ubuntu-classroom-chat with QUESTION: so that I notice it :-)
(02:04:57 PM) aquarius: So, firstly, what's desktopcouch?
(02:05:06 PM) aquarius: Well, it's giving every Ubuntu user a CouchDB on their desktop.
(02:05:17 PM) aquarius: CouchDB is an Apache project to provide a document-oriented database. If you're familiar with SQL databases, where you define a table and then a table has a number of rows and each row has the same columns in it...this is not like that.
(02:05:39 PM) aquarius: Instead, in CouchDB you store "documents", where each document is a set of key/value pairs. Think of this like a Python dictionary, or a JSON document.
(02:05:57 PM) aquarius: So you can store one document like this:
(02:06:00 PM) aquarius: { "name": "Stuart Langridge", "project": "Desktop Couch", "hair_colour": "red" }
(02:06:16 PM) aquarius: and another document which is completely different:
(02:06:19 PM) aquarius: { "name": "Stuart Langridge", "outgoings": [ { "shop": "In and Out Burger", "cost": "$12.99" } , { "shop": "Ferrari dealership", "cost": "$175000" } ] }
(02:06:46 PM) aquarius: The interface to CouchDB is pure HTTP. Just like the web. It's RESTful, for those of you who are familiar with web development.
(02:06:59 PM) aquarius: This means that every programming language already knows how to speak it, at least in basic terms.
(02:07:10 PM) aquarius: CouchDB also comes with an in-built in-browser editor, so you can look at and browse around and edit all the data stored in it.
(02:07:18 PM) aquarius: So, the desktopcouch project is all about providing these databases for every user, so each user's applications can store their data all in one place.
(02:07:31 PM) aquarius: You can have as many databases in your desktop Couch as you or your applications want, and storage is unlimited.
(02:07:43 PM) aquarius: Desktop Couch is built to do "replication", synchronizing your data between different machines. So if you have, say, Firefox storing your bookmarks in your desktop Couch on your laptop, those bookmarks could be automatically synchronized to your Mini 9 netbook, or to your desktop computer.
(02:07:54 PM) aquarius: They can also be synchronized to Ubuntu One, or another running-in-the-cloud service, so you can see that data on the web, or synchronize between two machines that aren't on the same network.
(02:08:05 PM) aquarius: So you've got your bookmarks everywhere. Your own personal del.icio.us, but it's your data, not locked up solely on anyone else's servers.
(02:08:19 PM) aquarius: Imagine if your apps stored their preferences in desktop Couch. Santa Claus brings you a new laptop, you plug it in, pair it with your existing machine, and all your apps are set up. No work.
(02:08:35 PM) aquarius: But sharing data between machines is only half the win. The other half is sharing data between applications.
(02:08:45 PM) aquarius: I want all my stuff to collaborate. I don't want to have to "import" data from one program to another, if I switch from Thunderbird to Evolution to KMail to mutt.
(02:08:57 PM) aquarius: I want any application to know about my address book, to allow any application to easily add "send this to another person", so that I can work with people I know.
(02:09:05 PM) aquarius: I want to be able to store my songs in Banshee and rate them in Rhythmbox if I want -- when people say that the Ubuntu desktop is about choice, that shouldn't mean choosing between different incompatible data silos. I can choose one application and then choose another, you can choose a third, and we can all cooperate on the data.
(02:09:14 PM) aquarius: My choice should be how I use my applications, and how they work; I shouldn't have to choose between underlying data storage. With apps using desktopcouch I don't have to.
(02:09:24 PM) aquarius: All my data is stored in a unified place in a singular way -- and I can look at my data any time I want, no matter which application put it there! Collaboration is what the open source desktop is good at, because we're all working together. It should be easy to collaborate on data.
(02:09:27 PM) aquarius: That's a brief summary of what desktopcouch *is*: any questions so far before we get on to the meat: how do you actually Use This Thing?
(02:10:33 PM) aquarius: mandel_macaque (hey, mandel :)) -- that's what the desktopcouch mailing list is for, so people can get together and talk about what should be in a standard record
(02:10:55 PM) aquarius: there's no ivory tower which hands down standard formats from the top of the mountain :)
(02:11:26 PM) aquarius: mandel_macaque's question was: will there be a "group" that will try to define standard records?
(02:11:35 PM) aquarius: <mhall119|work> QUESTION: how does desktopcouch differ from/replace gconf?
(02:12:05 PM) aquarius: mhall119|work, desktopcouch is for storing all sorts of user data. It's not just about preferences, although you could store preferences in it
(02:12:36 PM) aquarius: <sandy|lu1k> QUESTION: What about performance? Why would Banshee/rhythmbox switch to a slower way to store metadata?
(02:13:18 PM) aquarius: sandy|lu1k, performance hasn't really been an issue in our testing, and couchdb provides some serious advantages over existing things like sqlite or text files, like replication and user browseability
(02:13:34 PM) aquarius: <mandel_macaque> QUESTIONS: Is desktopcouch creating the required infrastructure to allow user sync, or should applications take care of that?
(02:14:06 PM) aquarius: desktopcouch is providing infrastructure and UI to "pair" machines and handle all the replication; applications do not have to know or worry about data being replicated to your other computers
(02:14:19 PM) aquarius: <jopojop> QUESTION: can you store media like images, audio and video?
(02:14:41 PM) aquarius: jopojop, not really -- couchdb is designed for textual, key/value pair, dictionary data, not for binary data
(02:15:37 PM) aquarius: it's possible to store binary data in desktopcouch, but I'd suggest not importing your whole mp3 collection into it; store the metadata. The filesystem is good at handling binary data
(02:15:57 PM) aquarius: <sandy|lu1k> QUESTION the real performance concern that media apps have is query speed for doing quick searches
(02:16:36 PM) aquarius: sandy|lu1k, that's something we'd really like to see more experimentation with. couchdb's views architecture makes it really, really quick for some uses,
(02:17:05 PM) aquarius: ok, let's talk about how to use it :)
(02:17:10 PM) aquarius: The easiest way to use desktopcouch is from Python, using the desktopcouch.records module.
(02:17:20 PM) aquarius: This is installed by default in Karmic.
(02:17:25 PM) aquarius: An individual "document" in desktop Couch is called a "record", because there are certain extra things that are in a record over and above what stock CouchDB requires, and desktopcouch.records takes care of this for you.
(02:17:37 PM) aquarius: First, a bit of example Python code! This is taken from the docs at /usr/share/doc/python-desktopcouch-records/api/records.txt.
(02:17:44 PM) aquarius: >>> from desktopcouch.records.server import CouchDatabase
(02:17:46 PM) aquarius: >>> from desktopcouch.records.record import Record
(02:17:47 PM) aquarius: >>> my_database = CouchDatabase("testing", create=True)
(02:17:48 PM) aquarius: # get the "testing" database. In your desktop Couch you can have many databases; each application can have its own with whatever name it wants. If it doesn't exist already, this creates it.
(02:17:59 PM) aquarius: >>> my_record = Record({ "name": "Stuart Langridge", "project": "Desktop Couch", "hair_colour": "red" }, record_type='http://example.com/testrecord')
(02:18:03 PM) aquarius: # Create a record, currently not stored anywhere. Records must have a "record type", a URL which is unique to this sort of record.
(02:18:26 PM) aquarius: >>> my_record["weight"] = "too high!"
(02:18:29 PM) aquarius: # A record works just like a Python dictionary, so you can add and remove keys from it.
(02:18:43 PM) aquarius: >>> my_record_id = my_database.put_record(my_record)
(02:18:44 PM) aquarius: # Actually save the record into the database. Records each have a unique ID; if you don't specify one, the records API will choose one for you, and return it.
(02:19:06 PM) aquarius: >>> fetched_record = my_database.get_record(my_record_id)
(02:19:07 PM) aquarius: # You can retrieve records by ID
(02:19:11 PM) aquarius: >>> print fetched_record["name"]
(02:19:11 PM) aquarius: "Stuart Langridge"
(02:19:15 PM) aquarius: # and the record you get back is a dictionary, just like when you're creating it.
(02:19:59 PM) aquarius: That's some very basic code for working with desktop Couch; it's dead easy to save records into the database.
(02:20:00 PM) aquarius: You can work with it like any key/value pair database.
(02:20:06 PM) aquarius: And then desktopcouch itself takes care of things like replicating your data to your netbook and your desktop without you having to do anything at all.
(02:20:16 PM) aquarius: And the users of your application can see their data directly by using the web interface; no more grovelling around in dotfiles or sqlite3 databases from the command line to work out what an application has stored.
(02:20:30 PM) aquarius: You can get at the web interface by browsing to file:///home/aquarius/.local/share/desktop-couch/couchdb.html in a web browser, which will take you to the right place.
(02:20:42 PM) aquarius: (er, if your username is aquarius you can, anyway :))
(02:20:48 PM) aquarius: I'll stop there for some questions about this section!
(02:21:24 PM) aquarius: ah, people in the chat channel are trying it out. YOu might need to install python-desktopcouch-records
(02:21:59 PM) aquarius: the version in karmic right now has a couple of strange outstanding bugs which we're working on which might make it a little difficult to follow along
(02:22:02 PM) aquarius: <mandel_macaque> QUESTION: (about views) which is the policy for design documents (views), one per app?
(02:22:34 PM) aquarius: mandel_macaque, no policy, thus far. Create whichever design docs you want to -- having one per app sounds sensible, but an app might want more than one
(02:22:48 PM) aquarius: mandel_macaque, this is an ideal topic to bring up for discussion on the mailing list :)
(02:23:14 PM) aquarius: <test1> QUESTION: Does desktopCouch/CouchDB provide a means controls access to my data on a per application basis? I would not necessarily want any application to be able to access any data - I might want to silo two mail apps to different databases, etc.
(02:23:51 PM) aquarius: test1, at the moment it does not (in much the same way as the filesystem doesn't), but it would be possible to build that in
(02:24:09 PM) aquarius: <mhall119|work> QUESTION: how does the HTML interact with couchdb?  Javascript?
(02:24:33 PM) aquarius: mhall119|work, (I assume you mean: how does the HTML web interface for browsing your data interact with couchdb?) yes, JavaScript
(02:24:43 PM) aquarius: <AntoineLeclair> QUESTION: so when I do CRUD, it's done locally, then replicated on the web DB? (and replicated locally from the web some other time to keep sync?)
(02:25:09 PM) aquarius: AntoineLeclair, yes, broadly
(02:25:19 PM) aquarius: <F30> QUESTION: So far, this sounds a bit like the registry which we all know and hate from the Windows world: Do you really think all applications should put there data into one monolithic databse, which in the end gets messed up?
(02:26:37 PM) aquarius: F30, having data in one place allows you to do things like replicate that data and make generalisations about it. We have the advantage that desktopcouch is built on couchdb, which is not only dead robust but also open source, unlike the registry :)
(02:27:15 PM) aquarius: <test1> In terms of replication - does CouchDb automate data merging (i.e. how does it handle conflict resolution) if I were to modify my bookmarks on multiple machines before replication took place?
(02:28:10 PM) aquarius: test1, couch's approach is "eventual consistency". In the case of actual conflicts, desktopcouch stores both versions and marks them as conflicting; it's up to the application that uses the data to resolve those conflicts in some way
(02:28:23 PM) aquarius: perhaps by asking the user, or applying some algorthmic knowledge
(02:28:41 PM) aquarius: the application knows way more about what the data is than couch itself does
(02:29:25 PM) aquarius: Next, on to views.
(02:29:31 PM) aquarius: Being able to retrieve records one at a time is nice, but it's not what you want to do most of the time.
(02:29:39 PM) aquarius: To get records that match some criteria, use views.
(02:29:48 PM) aquarius: Views are sort of like SQL queries and sort of not. Don't try and think in terms of a relational database.
(02:29:56 PM) aquarius: The best reference on views is the CouchDB book, available for free online (and still being worked on): the views chapter is at http://books.couchdb.org/relax/design-documents/views
(02:30:26 PM) aquarius: Basically, a view is a JavaScript function.
(02:30:29 PM) aquarius: When you request the records from a view, desktopcouch runs your view function against every document in the database and returns the results.
(02:30:46 PM) aquarius: So, to return all documents with "name": "Stuart Langridge", the view function would look like this:
(02:30:49 PM) aquarius: function(doc) { if (doc.name == "Stuart Langridge") emit(doc._id, doc) }
(02:31:01 PM) aquarius: This sort of thinking takes a little getting used to, but you can do anything you want with it once you get into it
(02:31:18 PM) aquarius: desktopcouch.records helps you create views and request them
(02:31:20 PM) aquarius: # creating a view
(02:31:21 PM) aquarius: >>> map_js = """function(doc) { emit(doc._id, null) }"""
(02:31:24 PM) aquarius: >>> db.add_view("name of my view", map_js, None, "name of the view container")
(02:31:27 PM) aquarius: # requesting the records that the view returns
(02:31:32 PM) aquarius: >>> result = db.execute_view("name of my view", "name of the view container")
(02:31:43 PM) aquarius: The "view container", called a "design doc", is a collection of views. So you can group your views together into different design docs.
(02:32:09 PM) aquarius: (hence mandel_macaque's question earlier about whether each app that uses the data in a database should have its own design doc(s). I suggest yes.)
(02:32:29 PM) aquarius: Advanced people who know about map/reduce should know that this is a map/reduce approach.
(02:32:41 PM) aquarius: You can also specify a reduce function (that's the None parameter in the add_view function above)
(02:32:48 PM) aquarius: The CouchDB book has all the information you'll need on views and the complexities of them.
(02:32:51 PM) aquarius: Questions on views? :-)
(02:33:07 PM) aquarius: <mandel_macaque> QUESTION: taking as an example the contacts record, when we have to perform a diff we will have to take into account the application_annotations key, which is share among apps. How can my app know aht to do with other app data?
(02:33:57 PM) aquarius: (bit of background for those not quite as au fait with desktopcouch: each desktopcouch record has a key called "application_annotations", and under that there is a key for each application that wants to store data specific to that application about this record)
(02:34:34 PM) aquarius: (so Firefox, for example, while storing a bookmark, would store url and title as top-level fields, and the Firefox internal ID of the bookmark as application_annotations.Firefox.internal_id or similar)
(02:35:02 PM) aquarius: mandel_macaque, what you have to do with data in application_annotations is preserve it. You are on your honour to not delete another app's metadata :)
(02:35:15 PM) aquarius: <mhall119|work> QUESTION: might it be better to standardize on views, rather than records?  So, Evolution and TBird might have their own database, with their own Contact record, but a single "All Contacts" view would aggregate both?
(02:35:58 PM) aquarius: mhall119|work, the idea behind collaboration is that everyone co-operates on the actual data rather than views. So it's better if each app stores the data in a standard format on which they collaborate, and then has its own views to get that data how *it* wants.
(02:37:37 PM) aquarius: <FND> mandel_macaque: what if I wanted to wipe all Firefox data because I want a fresh start? right now, I can just delete ~/.mozilla/firefox/myProfile
(02:37:37 PM) aquarius:  I'm concerned that as a power user, I lose direct access
(02:38:06 PM) aquarius: FND, you can delete the firefox database from the web interface, or from the command line. "curl -X delete http://localhost:5984/firefox"
(02:39:03 PM) aquarius: or using desktopcouch.records, which is nicer -- python -c "from desktopcouch.records.server import CouchDatabase; db = CouchDatabase('firefox'); db.delete()"
(02:39:28 PM) aquarius: <mgunes> QUESTION: Wouldn't deleting your profile simply reflect as deleted records on the CouchDB instance?
(02:40:18 PM) aquarius: mgunes, how deletions affect applications that used the deleted data depends on the application. For example, there's obviously a distinction between "I deleted this because I want to create a new one" and "I deleted this but I want to be able to get it back later"
(02:40:45 PM) aquarius: the couchdb upstream team are currently working on having full history for all records, which will make this sort of work easier
(02:41:01 PM) aquarius: <mhall119|work> QUESTION: if collaboration is to be done on the database level, there wouldn't be a "Firefox" database, there would be a "Bookmarks" database, correct?
(02:41:10 PM) aquarius: mhall119|work, yes, absolutely. My mistake in typing, sorry :)
(02:41:35 PM) aquarius: <mhall119|work> QUESTION: for those that don't want to mess with python of curl, will there be a CLI program for manipulating couchdb?
(02:42:13 PM) aquarius: mhall119|work, there isn't at the moment (curl or desktopcouch.records are pretty easy, we think) but I'm sure the bunch of talented people I'm talking to could whip up a program (or a set of bash aliases) in short order if there was desire for it
(02:42:16 PM) aquarius: :-)
(02:42:28 PM) aquarius: that would be a cool addition to desktopcouch
(02:42:40 PM) aquarius: <mandel_macaque> QUESTION: Since couchdb stores all the version of my documents, will we have something like time machine in OS X? The data will already be there :D
(02:43:13 PM) aquarius: mandel_macaque, certainly the infrastructure for that would be there once couchdb has full history and lots of apps are using desktopcouch
(02:43:21 PM) aquarius: if someone writes it I'll use it ;-0
(02:44:24 PM) aquarius: It's not just Python, though. The Python Records API is in package python-desktopcouch-records, but there are also others.
(02:44:35 PM) aquarius: couchdb-glib is a library to access desktopcouch from C.
(02:44:49 PM) aquarius: Some example code (I don't know much about C, but rodrigo_ wrote couchdb-glib and can answer all your questions :-))
(02:44:58 PM) aquarius: couchdb = couchdb_new (hostname);
(02:45:01 PM) aquarius: Create a database -> couchdb_create_database()
(02:45:02 PM) aquarius: Delete a database -> couchdb_delete_database()
(02:45:03 PM) aquarius: List documents in a database -> couchdb_list_documents()
(02:45:09 PM) aquarius: More details are available for couchdb-glib at http://git.gnome.org./cgit/couchdb-glib/tree/README
(02:46:07 PM) aquarius: We're also working on a library to access desktopcouch from JavaScript, so you can use it from things like Firefox extensions of gjs.
(02:46:19 PM) aquarius: er, *or* gjs :)
(02:46:29 PM) aquarius: And because the access method for desktop Couch is HTTP, it's easy to write an access library for any other language that you choose.
(02:46:31 PM) aquarius: You can, of course, talk directly to desktop Couch using HTTP yourself, if you choose; you don't have to use the Records API, or you might be implementing an access library for Ruby or Perl or Befunge or Smalltalk or Vala or something.
(02:47:04 PM) aquarius: desktopcouch.records (and couchdb-glib) do a certain amount of undercover work for you which you'll need to do, and to explain that I need to delve into some deeper technical detail.
(02:47:16 PM) aquarius: Your desktop Couch runs on a TCP port, listening to localhost only, which is randomly selected when it starts up. There is a D-Bus API to get that port.
(02:47:26 PM) aquarius: So, to find out which port you need to connect to by HTTP, call the D-Bus API. (This API will also start your desktop Couch if it's not already running.)
(02:47:36 PM) aquarius: $ dbus-send --session --dest=org.desktopcouch.CouchDB --print-reply --type=method_call / org.desktopcouch.CouchDB.getPort
(02:47:54 PM) aquarius: (desktopcouch.records does this for you.)
(02:47:57 PM) aquarius: You must also be authenticated to read any data from your desktop Couch. Authentication is done with OAuth, so every HTTP request to desktopcouch must have a valid OAuth signature.
(02:48:11 PM) aquarius: The OAuth details you need to sign requests are stored in the Gnome keyring.
(02:48:16 PM) aquarius: (again, desktopcouch.records takes care of this for you so you don't have to think about it.)
(02:48:36 PM) aquarius: As I said above, every record must have a record_type, a URL which identifies what sort of record this is. So, if your recipe application stores all your favourite recipes in desktopcouch, you need to define a URL as the record type for "recipe records".
(02:48:49 PM) aquarius: That URL should point to a human-readable description of the fields in records of that type: so for a recipe document you might have name, ingredients, cooking instructions, oven heat.
(02:48:59 PM) aquarius: The URL is there so other developers can find out what should be stored in a record, so more than one application can collaborate on storing data.
(02:49:10 PM) aquarius: If I write a different recipe application, mine should work with records of the same format; that way I don't lose all my recipes if I change applications, and me and the developers of the first app can collaborate.
(02:49:26 PM) aquarius: Let's take some more questions.
(02:49:42 PM) aquarius: <mgunes> QUESTION: Is there any plan/need for Desktopcouch itself to talk to Midgard, for access to data stored by applications that use it? And did you investigate Midgard before going with CouchDB?
(02:50:02 PM) aquarius: There's been a lot of conversation between Midgard and CouchDB and desktopcouch and others
(02:50:19 PM) aquarius: midgard implements the CouchDB replication API, so you can replicate your desktopcouch data to a midgard server
(02:50:35 PM) aquarius: <FND> to clarify, another way to express my concerns - and I hate to be such a nagging naysayer here - is "transparency" - inspecting files is generally a whole lot more obvious than inspecting a DB (even if there's a nifty web UI)
(02:51:21 PM) aquarius: FND, applications are increasingly using databases rather than flat files anyway, because of the advantages you get from a database -- as was asked about above, media players are using sqlite DBs and so on for quick searchability and indexability
(02:51:40 PM) aquarius: <bas89> QUESTION: is couchDB an ubuntu-only project or will it be avaiable on fedora or my mobile phone?
(02:52:18 PM) aquarius: couchdb runs, like, everywhere. It's available on Ubuntu, Fedora, other Linux distros, Windows, OS X...
(02:52:37 PM) aquarius: the couchdb upstream project love the idea of things like mobile phones running couch, and they're working on that :)
(02:53:34 PM) aquarius: desktopcouch, which sets up an individual couchdb for every user, is all written in Python and doesn't do anything Ubuntu-specific, so it should be perfectly possible to run it on other Linux distros (and there's a chap looking at getting it running on fedora)
(02:53:54 PM) aquarius: and since it's all Python it should be possible to have it on other platforms too, like Windows or the Mac.
(02:54:30 PM) aquarius: <FND> QUESTION: by making applications rely on CouchDB, isn't there a risk of diverging from other distros
(02:55:06 PM) aquarius: desktopcouch isn't Ubuntu-specific. There was lots of interest at the Gran Canaria Desktop Summit this year
(02:56:48 PM) aquarius: There is an Even Easier way to have applications use desktop Couch for data storage.
(02:56:48 PM) aquarius: One of the really cool things in karmic is Quickly: https://wiki.ubuntu.com/Quickly
(02:56:49 PM) aquarius: quickly helps you make applications...quickly. :-)
(02:57:09 PM) aquarius: and apps created with Quickly use desktopcouch for data storage.
(02:57:11 PM) aquarius: If you haven't seen Quickly, it's a way of easily handling all the boilerplate stuff you have to do to get a project going; "quickly create ubuntu-project myproject" gives you a "myproject" folder containing a Python project that works but doesn't do anything.
(02:57:15 PM) aquarius: So you can concentrate on writing the code to do what you want, rather than boilerplate to get started.
(02:57:18 PM) aquarius: It's dead neat :)
(02:57:20 PM) aquarius: Anyway, quickly projects are set up to save application preferences into desktop Couch by default. So you get the advantages of using desktop Couch (replication, browsing of data) for every quickly project automatically.
(02:57:26 PM) aquarius: The quickly guys have also contributed CouchGrid, a gtk.TreeView which is built on top of desktopcouch, so that it will display records from a desktopcouch database.
(02:57:39 PM) aquarius: "quickly tutorial ubuntu-project" has lots of information about CouchGrid and how to use it.
(02:57:41 PM) aquarius: Any questions about quickly? (I can't guarantee to be able to answer them, but #quickly is great for this.)
(02:57:48 PM) aquarius: I'm going to race throught he last section since I have 3 mins, and then try and answer the last few questions :)
(02:57:53 PM) aquarius: So, who's already using desktopcouch?
(02:57:59 PM) aquarius: Quickly, as mentioned, uses desktopcouch for preferences in projects it creates.
(02:58:02 PM) aquarius: The Gwibber team are working on using desktopcouch for data storage
(02:58:05 PM) aquarius: Bindwood (http://launchpad.net/bindwood) is a Firefox extension to store bookmarks in desktopcouch
(02:58:18 PM) aquarius: Macaco-contacts is transitioning to work with desktopcouch for contacts storage (http://www.themacaque.com/?p=248)
(02:58:21 PM) aquarius: (perhaps :-))
(02:58:23 PM) aquarius: Evolution can now, in the evolution-couchdb package, store all contacts in desktopcouch
(02:58:26 PM) aquarius: Akonadi, the KDE project's contacts and PIM server, can also store contacts in desktopcouch
(02:58:29 PM) aquarius: These last three are interesting, because everyone's collaborating on a standard record type and record format for "contacts", so Evolution and Akonadi and Macaco-contacts will all share information.
(02:58:31 PM) aquarius: So if you switch from Gnome to KDE, you won't lose your address book.
(02:58:34 PM) aquarius: I'm really keen that this happens, that applications that store similar data (think of mail clients and addressbooks, as above, or media players storing metadata and ratings, for example) should collaborate on standard formats.
(02:58:37 PM) aquarius: Details about the desktopcouch project can be found at http://www.freedesktop.org/wiki/Specifications/desktopcouch
(02:58:40 PM) aquarius: There's a mailing list at http://groups.google.com/group/desktop-couchdb
(02:58:43 PM) aquarius: The code is developed in Launchpad: http://launchpad.net/desktopcouch
(02:58:44 PM) aquarius: The best place to ask questions generally is the #ubuntuone channel; all the desktopcouch developers are hanging out there
(02:58:48 PM) aquarius: The best place to ask questions that you have right now is...right now, so go ahead and ask in #ubuntu-classroom-chat, and I'll answer any other questions you have!
(02:58:50 PM) aquarius: in the two minutes I have remaining ;-)
(02:59:16 PM) aquarius: <bas69> QUESTION: whats about akonadi? is there competition?
(03:00:01 PM) aquarius: akonadi has a desktopcouch back end for contacts, which was demonstrated at the Gran Canaria Desktop Summit -- it's dead neat to save a contact with Akonadi and then load it with Evolution :)
(03:00:11 PM) aquarius: <alourie> aquarius: QUESTION: does that mean that ubuntuone also uses it?
(03:01:16 PM) aquarius: desktopcouch lets you replicate your data between all your machines on your network -- Ubuntu One has a cloud service so you can also send your data up into the cloud, so you can get at it from the web and replicate between machines anywhere on the internet
(03:01:33 PM) aquarius: mgunes, yes indeed :)
(03:01:53 PM) aquarius: ok I need to stop now, out of time. Next is kees, who I hope will forgive me for overrunning!