incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Chance of including CouchDB in Linux distros or desktops?
Date Fri, 06 Mar 2009 20:23:21 GMT
On Thu, Mar 05, 2009 at 11:26:08PM +0100, Jan Lehnardt wrote:
>> This is all future-talk.
>
> This is what this thread is about.

I interpreted it as "why can't we get desktop distros to start integrating
couchdb *now*?"

(Searches archives) OP said:

"What are the chances that the free software movers and shakers could 
successfully lobby CouchDB to be included in the Freedesktop.org system?"

...

"I'm asking if it's desirable that modern distros bundle a document DB
(Couch) for all apps to build from."

This to me sounds like a request for today: "modern" distros rather than
"future" distros.

>> 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 :)
...
> 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.

Yes. And it picks the winner using a completely arbitrary algorithm which
you have no control over. So anyone who was replicating their laptop
(containing the most recent version of their work) to their desktop
(containing an older one) will, with a 50/50 chance, see the laptop revert
to the older version of the file when they next try to open it.

Yes, I *know* the other document is there, on both sides. If you construct a
suitable couchdb query, you can even find it and retrieve it.

At the moment there's no front-end which makes this process half decent. In
any case, any "generic" front-end could, at best, show you all the versions
side by side and ask you to pick the right one by hand, as it has no way of
knowing which is the best one. It can't even do what Unison does, which is
to assume that if the document changed at side A but didn't change at side
B, then side A is the preferred one.

Alternatively, you could try to have automatic resolution. This is
application-specific, that's to say, specific to the format of the JSON
documents in question, and what extra fields they may or may not include for
this purpose (such as timestamps). There's no framework in place where you
can plug in conflict-resolution rules yet, so everyone has to build their
own, externally.

Even if you have sufficient knowledge of your document structure to perform
automatic merging, CouchDB won't give you sufficient history (back to a
common ancestor) if compaction has taken place.

If you want all this, then right now git is a much better tool to build on.
Doesn't have anything like Couch's performance of course.

>> 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?

I think you misunderstand me, or I did not word carefully.

What I meant is CouchDB works pretty well, and has done so for a while - so
it's "stable" by that meaning of the word.

CouchDB is also changing and developing lots. This is also good in many
ways. But it's the last thing you want for integrating into a desktop distro
which may have a support lifecycle of 1-4 years.

If desktop distros had included 0.8.1, then probably all apps would have to
stick with the 0.8.1 API for that span of time. The alternative is to
release 0.9.0 and break all the apps which used it.

> 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.

But should it be "lobbied" for??

> 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)

Of course. If it solves your specific problem today, then go for it. But is
it ready today to be a foundation piece of the O/S itself?

> Sorry if that sounds cranky, but nobody said "CouchDB will make desktops
> more awesome today and immediately". It was a request for discussion.

No problem, I'm happy to discuss.

FWIW, I don't think CouchDB's strengths particularly play to the desktop. If
you're considering it as a gconf replacement, it's overkill (CouchDB
provides huge write/read/index performance, which isn't needed). If you want
to turn your entire filesystem into a CouchDB store, and index all your
documents, that's interesting but I'm not sure that's under discussion. I
also seem to recall that Microsoft tried this a few years ago, and failed...
although maybe the time is right to try again.

But then again, CouchDB semantics don't map particularly well to POSIX-type
filesystems either.

Would it be cool to store my mailbox in CouchDB rather than Maildir?
Perhaps, but unless you also provide an IMAP front-end, I doubt the MUA
writers are going to write Couch-HTTP backends for their code. In any case,
saying "use CouchDB" for this is like saying "use XML" - without a standard
for the format of the JSON metadata and the views, different consumers of
mailboxes won't be able to share data.

So in summary - I don't yet see a need for a kick-ass data warehouse on a
GUI desktop plugged into DBus. And I believe that if and when one is needed,
the application will push adoption of the database, rather than vice versa.

Regards,

Brian.

Mime
View raw message