- Startup scripts for a "personal" desktop Couch
- A D-Bus "port advertiser": because the scripts start up your desktop Couch on a random port, you need to find out which port that is, and so there's a tiny D-Bus API which returns the port number
- The D-Bus API is designed to be run from D-Bus activation; if your desktop Couch isn't running then it is started by the D-Bus API. This means that your desktop Couch isn't running on startup, so startup time isn't affected, but the first time anything tries to use it it is started.
- Pairing between two of your desktop Couches. This isn't finished yet, but this is for sharing your data between two of your machines. Say you've got a laptop and a netbook; you pair those two machines and then any data in one appears in the other. So, if you're storing your Firefox bookmarks in your desktop Couch then adding a new bookmark on your netbook will cause it to appear on your desktop. All this pairing works on your local network; it doesn't use a server out there on the internet. (Nice work, Chad!)
- The Records API. As noted earlier in these pages we're all talking about having a few extra fields in each document in a desktop Couch to add some extra useful infrastructure. CouchDB documents with these fields in we're calling "records".
record_typeandrecord_type_versionare to help you know what type of thing a record describes. The standard way of storing a list as a uuid-keyed dictionary helps when replicating data around between paired desktop Couches. This "Records API" is a Python API for accessing your desktop Couch; it handles the record_type stuff and the MergeableList stuff for you, and it also takes care of things like doing the D-Bus call to find out your desktop Couch's port number. (Note that it'll "fall back" to a system-level CouchDB on port 5984, so if you want to experiment you don't need a desktop Couch up and running!)
And this is Desktop Couch initial code, written , and concerning CouchDB
The idea of putting CouchDB on every desktop has been getting a lot of play at GCDS this week, which is cool. Some of the stuff we've been working on is to do with the infrastructure of that, and we* found time to separate this out into a separate project, desktopcouch on Launchpad. There's a few things in there already:
Comments
Gary Fleming
sil
Gary,
A number of things. If I decide to switch from, say, Evolution to Thunderbird, how do I get my addressbook? I have to export and reimport it, or maybe if I'm lucky Thunderbird implements direct import from Evolution. But why should I have to do that manual step? All my applications should use the same address book. All my applications that store notes should use the same notes database. All my applications that use bookmarks should use the same bookmarks database. So, part 1 of the plan is to have shared data between applications.
Next thing: my data's pretty opaque; it's fiddly to get at data for SomeRandomApp without using SomeRandomApp. Now, maybe the app uses SQLite for its databases, meaning that there is at least some way of getting at the data, but SQL's still not that user-friendly. So, part 2 of the plan is to make application data easily visible to the user if they want to see it.
Next thing: people increasingly have multiple computers. They might have a desktop and a laptop, or a laptop and a netbook, and you have to set them all up separately. If you pair the two machines, the second one you buy takes no time to set up at all. So, part 3 of the plan is having the same data on all my computers, without having to set up my own server on the internet or my LAN or trust my data to a third party.
More: if all your data's in one place then backing it up becomes easy. If you want to trust your data to a third party, or to store it in Ubuntu One or similar so you can get at it from the web or from your friend's computer or from an internet cafe, then it's easier to do that.
zulu
i like this whole couchdb idea.
a few question though: what happens if can't establish an internet connection or suddenly my internet connection breaks? will i get a data loss and will all apps connected to couch db stop responding?
will there be something like a local couchdb service/proxy that buffers all data localy when no connection is available and syncs it when it becomes available? something like the decentralized branching concept in bazaar maybe?
sil
zulu: no internet connection is required at all. CouchDB runs on your computer, and applications store data in that CouchDB directly on your computer without having to hit the network at all.
László Torma (toros) 's status on Thursday, 09-Jul-09 11:16:49 UTC - Identi.ca
[...] http://www.kryogenix.org/days/2009/07/09/desktop-couch-initial-code [...]
curious
nepomuk is supposed to do that kind of stuff. so why exactly are you reinventing the wheel again?
Lumbar
Isn't that exactly what Akonadi is? Only that Akonadi already works.
http://pim.kde.org/akonadi/
curious
well, akonadi relies upon kdelibs. nepomuk, on the other hand, is just the storage which can be used independently from de.
zulu
oh then i confused this project somehow with ubuntu one which uses couchdb as well. i thought this would abstract ubuntu one in someway, so that it is more distro independent.
sulfide
I've got to say most times I don't really read your blog on my rss, but I think this is a great idea. Sorry guys, couch looks far better than these other pieces of pooh, also as a developer the couch website is much more clear and easier for developers too. I think this would be great, one of the first things in while I'd be excited to see going on in linux desktop land.
Félim Whiteley
Aq this is exactly what Akonadi is doing right now, and it was designed to be Desktop agnostic, there's even a picture with gnome-libs in it talking to Evolution etc. (And if it's in a picture it must be true) I do remember in one LR episode complaining about freedesktop and KDE and how Gnome seems to use it and KDE didn't. Is the kettle on the other foot? I'm sort of joking but be interested why you are reinventoing it.
sulfide
how is he re-inventing anything? couch already exists, you just have to use it as a conduit..just like you would akonadi. He is simply choosing a much better tool.
curious
@Felim: oops, you're right :)
@sulfide: how exactly is it better?
Alex
@curious: I don't think Akonadi has the automatic and robust replication features. I suspect Akonadi will ultimately have an agent for the CouchDB system.
curious
i've no idea why you guys compare Akonadi/NEPOMUK with a persistent storage. the former uses persistent storage (mysql, sqlite, you name it), whereas couchdb is just one of those storages which can be used.
jorge
Steve Alexander demoed an akonadi agent talking to couch yesterday at the Gran Canaria Desktop summit.
sil
Alex: akonadi already has a resource to store data in CouchDB, built as part of the desktop Couch project. It was demonstrated at GCDS.
James Westby (jamesw) 's status on Thursday, 09-Jul-09 15:19:01 UTC - Identi.ca
[...] @j1mc: see the comments of http://www.kryogenix.org/days/2009/07/09/desktop-couch-initial-code [...]
Maciej Piechotka
I still cannot find out how it will "improve my desktop experience". Getting data via network stack is terrible as performance is concerned. Http would not be a rocket as well. When communicating by network it does not have an impact - but in IPC it may have impact.
And as far as migration is concerned - specifing formats will do much more as otherwise. No cauchdb will save from having Surname vs. FamilyName vs. family_name vs...
sil
Maciej: this is why there's discussion ongoing about formats, as per previous posts. :)
Walther
@Maciej (and others): It is not getting data over the network. You're getting the data from the db on your own machine. Synchronization with other machines is of course going over the network, but that happens in the background, so you won't even notice that.
ZaumA
Condsider editing this....." There’s a" to, 'There are a few things' (things being plural.)
Consider changing button to read 'Send Comment':-)
links for 2009-07-10 « Breyten’s Dev Blog
[...] as days pass by, by Stuart Langridge — Desktop Couch initial code (tags: couchdb desktop project) [...]
Ryan Paul (segphault) 's status on Saturday, 11-Jul-09 00:42:13 UTC - Identi.ca
[...] http://www.kryogenix.org/days/2009/07/09/desktop-couch-initial-code [...]
John Drinkwater
Great idea - I want a global system address book. But why not with methods that are better modelled to our current OS everything-is-a-file - vCards.
~/Contacts/ containing a pool of files that are my friends and fam, they can sync with any method I choose..
~/Notes/ etc..
Isn’t this something freedesktop would love to have a say in?
Mandel
Hey,
I got a message from Steve (steve@canonical) from reddit because of the following submission I made: http://www.reddit.com/r/programming/comments/91bna/address_book_apple_look_like_for_linux/
It looks like we though alike!! It would be great to try and work together to get some really cool stuff going.
Let me know :D
James
I was reading your IRC presentation logs (https://wiki.ubuntu.com/MeetingLogs/devweek0909/CouchDB), and wondering how to get started without installing a Ubuntu Karmic alpha.
Is there a package for Jaunty, or any other distro? What do I need - Apache, CouchDB and the Python package(s)?
Speaking of Apache - does this mean every Karmic user will have a local web server running on his machine? Isn't that a bit risky, both in terms of security and performance?
sil
James: I've answered your question in the comments at http://www.kryogenix.org/days/2009/09/03/desktop-couch-irc-talk because it was probably a better place to put the answer :)
I'm curious, what are the real goals of this project? Putting CouchDB on every desktop is obviously an implementation rather than a goal, so what are you looking to get out of it?
Syncing bookmarks (locally or remotely) is a solved problem, as is contacts. Sadly, real users (i.e. not people like you or I who hack on Linux) don't actually care about these things all that much.
So, genuinely, what is the plan?