couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb:
Date Tue, 28 Sep 2010 15:10:38 GMT
On Tue, Sep 28, 2010 at 3:10 AM, Benoit Chesneau <> wrote:
> On Mon, Sep 27, 2010 at 11:53 PM, Chris Anderson <> wrote:
>> we need to specify the protocol in the file, as you could potentially
>> have a single couchdb server listening on multiple ports with multiple
>> protocols. (or even on a non-standard port, like https on 8888 or
>> something)
>> so the file could have multiple lines corresponding the the addresses
>> the server is listening on.
>> does that make sense?
> Well this file is here to allow a local application to speak with
> couchdb more easily than looking all the pid and associate port on
> them. What currently does desktopcouch btw.  I don't see to have the
> point to have multiple url here just one for the localhost.

IMO, either we dump all places CouchDB is listening or none at all. I
don't see it being very easy to figure out from our end, which ip/port
a user will want without dumping them all. As you point out, generally
this is for configurations where they're trying to hit couch locally
so in practice it will most likely only have a single line (when its
used) anyway.

> About ssl + non ssl, well I'm currently asking myself if it's good to
> have have same server sending the same data encrypted or not. My logic
> fails here.

I see your point, but I don't think this is something we should
enforce at the server level. At the most, perhaps having a startup
message that indicates that there are two adapters with different
encryption levels or some such.

> About /var/run vs /var/lib, that just sometimes you gave different
> privileges on this folders, giving the possibility to read one or not.
> This is not only a question of giving a "state". I'm actually thinking
> that we may want to have this info in /tmp path  where we save
> generally such info. Dbus does this, mysql does this for the socket
> (by default) ...  /tmp is available for everyone. While /var/run  is
> working for root apps, it doesn't for apps launched per users. At
> first I thought that lib folder was good since the couchdb user have
> access to it. But /tmp may be more appropriate so I could do such
> scenario :
> 1. Launch couchdb as benoitc user
> 2. Let my guest know the port by loocking in /tmp/benoitc-couchdb.url

I think the issue here is that the CouchDB roles are getting confused.
Benoit is correct that most of the time that people use this
particular feature, it will be for things like desktopcouch. As such,
we need to make sure that they can use this feature easily. For
instance, the path to this file needs to be configurable so that it
can be placed anywhere the desktopcouch people see fit.

OTOH, the default CouchDB role is to be a server. So, by default it
should act like a server. According to FHS guidelines, temporary files
that reflect the state of running daemon (which may or may not be
valid for the next instance of the daemon) are supposed to be placed
in /var/run/.

> What do you think about it?
> benoit
> ps. sorry for late answer, was difficult to find time during jsconf for this.

It occurs to me that perhaps its time that we define a set of "roles"
or "scenarios" for CouchDB deployment. Like those things where they
used "In the case of Sally" shorthand to define a whole bunch of
assumptions. For instance, we've got server, cluster, mobile, desktop,
and ISS computers. Now we just need to define constraints for each

Or something...

Paul Davis

View raw message