Re: Couchdb package

[Sam Bisbee <sbisbee@computervip.com>]

On Sun, Jan 17, 2010 at 08:45:43AM +0100, David Paleino wrote:
> On Sunday 17 January 2010 07:34:37, Sam Bisbee wrote:
> > The only "upstream decision" that I know of is that system wide deployment
> >  is their default configuration and there's no built in per-user support
> >  that I know of. I don't know if it was a conscious decision or not, but
> >  there it is.
> > 
> > As an aside, I'm not saying that per-user couches isn't interesting (I
> > especially like the implications for shared hosting environments). I think
> >  that it's going to need better support than what's been proposed though
> >  (Sergei's/my first thoughts with attn. to the list of items,
> > http://lists.alioth.debian.org/pipermail/pkg-erlang-devel/2009-November/000
> > 056.html). I would encourage someone to go upstream with the changes and
> >  see about implementing them there. Their dev@ would probably be the best
> >  bet. I can also forward it from the "Debian desk" if someone wants me to.
> 
> Then please do :)

I just had a thought while writing my e-mail to the dev@ list...

What if this was done as an auth module that used local system users instead of
a more general configuration? This would allow you to control database and
document access on a per-user, or per-group, basis. You would still have one
system wide instance, and whether it starts at boot or on demand is easily
taken care of by config files. 

You also take out the part that I always thought was odd during this
discussion: if even one user wants an instance, then it's more efficient IMHO
to start one instance than potentially starting one instance per user (1 is
better than N, even if N is 0). The only benefit that I see to per-user
instances is the auth issues, but that'd be taken care of by the auth module
and validation functions.

This way you could allow different users to use the same database, which might
be nice for some applications. It also takes care of the nasty questions like
whether the database should be able to talk to external interfaces (network,
USB, serial, etc.), where to keep logs and database files, etc.

This should also scale well for distributed deployments, assuming that the
users' accounts are shared between machines (probably less well when sharding).
Instead of building an auth module for SASL, then LDAP, etc. you could just use
the system accounts that already support all those systems.

I'd be much happier suggesting this approach than the per-user one.

Thoughts?

-- 
Sam Bisbee