On Tue, Sep 28, 2010 at 3:10 AM, Benoit Chesneau <[email protected]> wrote: > On Mon, Sep 27, 2010 at 11:53 PM, Chris Anderson <[email protected]> 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 one. Or something... Paul Davis
