couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Melloy <>
Subject Re: Chance of including CouchDB in Linux distros or desktops?
Date Fri, 06 Mar 2009 00:16:53 GMT
On Thu, Mar 5, 2009 at 2:26 PM, Jan Lehnardt <> wrote:
> On 5 Mar 2009, at 18:56, Brian Candler wrote:
>> On Thu, Mar 05, 2009 at 03:31:43PM +0000, Alan Bell wrote:
>>> Noah Slater wrote:
>>>> What actual problem would this solve?
>>> well I think that is the discussion point. It certainly raises a few
>>> interesting thoughts. One of the suggestions was a couchdb process per
>>> user. Not quite sure about this one, sounds like it might not scale well
>>> with multiple users. One database per user might well be handy. It could
>>> perhaps replace the gconf database.
>>> If it could do everything for a user, perhaps even with a FUSE
>>> filesystem pointing at the users database mounted at /home/user then the
>>> replication between machines would be quite cool, particularly for
>>> laptops.
>> This is all future-talk.
> This is what this thread is about.
>> Until couchdb has some half-decent way of resolving conflicts - either a
>> front-end for doing it manually (such as in futon) and/or via
>> application-specific programmatic rules - it doesn't cut. As far as the
>> user
>> is concerned, updated documents vanish at random.
> Sorry, but WTF? This is bollocks :)
>> For now I will stick with unison, which at least tells me there are files
>> with conflicting updates and leaves the state at both ends unchanged.
> CouchDB sets _conflics = [list of conflicting revs] in a conflicting doc
> and a map-only-view gives you a list of all conflicting docs and the
> app can easily resolve them.
>> IMO it's also a long way before couchdb becomes stable enough to become an
>> integral part of the desktop (by "stable" I mean "not constantly
>> changing",
>> rather than "working properly")
> Oh hey, can I get a few more JIRA's from you? Also, CouchDB has
> been labelled alpha ver clearly. A in-flux API does not mean integration
> into a desktop system can be *started* to be talked about.
> For that matter, nobody should use CouchDB in the current state, yet
> some have done so since the 0.7. releases (which ran till ~Dec 2008 and
> are now on 0.8)
> Sorry if that sounds cranky, but nobody said "CouchDB will make desktops
> more awesome today and immediately". It was a request for discussion.
> Cheers
> Jan
> --

Off the top of my head, I can think of quite a few situations where
having a data store that replicates point-to-point would be useful.

Bookmarks have already been mentioned: add a bookmark on one machine,
sit down at the other and it's automatically there. Browser history,

Address books are a decent example for replication, but they're a
pretty good example of a system where you might want to store
different pieces of information about different people.

Another thought would be something similar to DevonTHINK or Yojimbo.
If you're unfamiliar, they're sort of desktop databases. Each allows
you to keep a variety of types and styles of notes (and completely
rich media) without you having to think about the filesystem. If they
were backed by couchdb they could be replicated and backed up among
all of your machines.

And, lastly, configuration file management. Who's had to say, "What's
different between these two machines" or have problems in the push
from development to production or production box #1 to production box

My thinking is that if you have a good product and you work to make it
ubiquitous, you'll get people using it in a lot of ways you don't


View raw message