On Thu, Mar 05, 2009 at 10:44:58PM +0700, Jason Smith wrote: > 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. > > Well, gconf has its own API and should probably be "up" even in bad > situations like a full disk or when the OOM killer starts spraying > bullets into the process space.
Oh man, that's such a great mental image. Guess it helps when you've had to firefight OOM killer on production machines. > (To play Devil's advocate, my argument could be made for MySQL too and > we don't see that happening. Some might say that it's just a bad idea, > but I would still argue that Linux desktop developers are simply > uncreative.) I'm sure someone will disagree with me here, but I think that the problem stems from the server/client model. While this architectural constraint is great for distributed hypertext systems, which is what we're designing CouchDB for, it's not so great when you're trying to re-purpose it for local use. That's the difference between MySQL and SQLite. If someone could adapt CouchDB into CouchLite or something similar... -- Noah Slater, http://tumbolia.org/nslater
