incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <d...@deanlandolt.com>
Subject Re: Chance of including CouchDB in Linux distros or desktops?
Date Fri, 06 Mar 2009 01:09:37 GMT
On Thu, Mar 5, 2009 at 7:16 PM, Jeffrey Melloy <jmelloy@gmail.com> wrote:

> - Show quoted text -
> On Thu, Mar 5, 2009 at 2:26 PM, Jan Lehnardt <jan@apache.org> 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,
> too.


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


Most of these examples are pretty much right in line with what Mozilla
Weave's aiming for. Of course, it'd be awfully sweet if they offered up a
couch backend (I bet it'd beat the shit out of their flakey-ass webdav).


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


I think it's pretty easy to think of dozens of cool uses of couch on the
desktop, but I get the thrust of Noah's argument. In each of these cases, if
couch is the right tool for the job, it can always be installed as needed by
the desktop app.

Of course, it'd be great if there were as simple a couch install story on
windows as on linux and mac, but I think Jan already threw that out there as
an idea for a summer of code project (Antony's even been offering a bounty
for it -- hopefully someone bites).


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


[emphasis mine] -- speaking of Mozilla, another project (already using couch
for their command sharing) that could get a huge boost from having a local
couch as a nountypes store, if you're into that kinda thing...

All I'm saying is the easiest way to get a couch on every desktop, so to
speak, is to not through a Freedesktop spec but as an infrastructure include
in other successful cross-platform open source desktop projects.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message