Why do you insist on blocking or re-inventing the work done in desktopcouch? We've already shipped integration with e-d-s, Firefox, tomboy, and quickly. People are working on integration with akonadi, gtg, gwibber, and more. Desktopcouch was written over months of close collaboration with core couchdb developers.
Your previous suggestions about per-user couchdb advocated preventing per-user instances from being able to use the network, which would completely break replication, and now you want to start from zero without looking at what has been accomplished already. The fact that the upstream tarball happens to contain an init script in no way justifies you blocking the desktop couchdb efforts.
I don't think debian has any obligation to accept patches from Ubuntu, but it really bums me out to see this kind of reception when my team went to big efforts to make sure that desktopcouch was not Ubuntu specific, and we paid for some fixes to core couchdb so they would be available to everyone. Now some debian developers come along and ask why you are refusing to accept the patch to split the init script into a separate package in a way that causes no surprises for users or developers, and you continue to reject it without any technical basis.
There are no questions about where to keep log files, etc. This is all already handled in desktopcouch. You are muddying the waters with non-issues. The only question is why you refuse the change, and you have not provided any sound reason for that.
It doesn't hurt my feelings any if debian users of applications that integrate with desktopcouch suffer a slightly longer boot time due to your refusal to allow the package split. It does bug me to see spreading of FUD about desktopcouch saying there are all kinds of unsolved design problems about how couchdb supports per-user instances.
1 is better than N even when N is zero? Absolutely not.
--
Elliot Murphy | https://launchpad.net/~statik/
On Jan 17, 2010 12:08 PM, "Sam Bisbee" <sbisbee@computervip.com> wrote:On Sun, Jan 17, 2010 at 08:45:43AM +0100, David Paleino wrote: > On Sunday 17 January 2010 07:34:37,...
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