locally registered names prevent multiple configurations

[okeuday]

Dependent applications are unable to instance couchbeam multiple times and the main problem with doing so is the locally registered names: "couchbeam_manager" and "lhttpc_manager" (within the dependency lhttpc). It is common for useful libraries to avoid registered names, since it can cause conflicts with other applications. couchbeam would benefit from changes that do not depend on starting it as a single application instance. Otherwise users of couchbeam will be unable to talk to multiple couchdb databases. It is possible you could handle the problem with more locally registered names, but that would involve changes in the wrong direction, based on other Erlang database drivers.

[okeuday]

I have a possible alternative solution/implementation that represents a way of doing things without locally registered names and is an adaptation from a different erlang couchdb driver (though it probably doesn't support all the features found in couchbeam). The code exists at: http://github.com/okeuday/CloudI/tree/master/src/lib/ecouchdb/src/

[benoitc]

well some other libs use {ServerUri, Port} as param. There is a way anyway to not tegister db and server. lhttpc is needed to share and maintain connections open. If you don't do this it will open a connection for each call you make. I will try to provide a patch to not register db and server.

[benoitc]

Checking your code, your simply doing the same thing that already do erlang_couchdb. that is not the path followed by couchbeam right now and won't.

[okeuday]

If you do not want to change your code, that is fine. I just was hoping to reduce duplicated effort. Ignore the issue then please.

[sendtopms]

@okeuday You can have multiple configuration by having one registered name for one db. This would work even for dynamic creation of db too.

[okeuday]

The configuration is not dynamic. You are talking about manual code editing which is on par with hacking. If it was changed to support dynamic registered names, it is still using registered names, which is still a problem because of name conflicts that can occur. This can be just a difference of opinion on how to develop the driver, so why don't we ignore my opinion. I already have an alternative for people to use if they are concerned about these issues.

[sendtopms]

I think I didn't put it well, here is what I meant, Example code would be Connection = couchbeam_server:start_connection_link(#couchdb_params{host="localhost",port=5984}), couchbeam_db:open(Connection, {yourdb, "yourdb"}), Here, yourdb is the name of the database. This is not a hack but one of the right way of using couchbeam. I guess benoit can verify this.

[sendtopms]

You would do this in application startup time and later you can refer DB by "yourdb". Since couchbeam is OTP application, your application can, at the start, initiate the above call to set things up.

[okeuday]

So even if the registered names for the database are dynamic, there are still registered names being used. I assume the http library still has its registered name also. This can work but is not typically how you want a driver. A driver is more consistent and easier to integrate if it acts as a library you instantiate... it returns a pid to operate on and doesn't pollute the global namespace with arbitrary registered names. The problem is the same... I really don't want to direct someone elses project, this was just a suggestion.

[benoitc]

I don't see how it pollute the namespace. Depends on your need but you could rearange the deps and share between all your applications like you do with any otp applications. Also here we need a pool system for http connections which is provided by lhttpc. We need it running every time. That to not use too much fd. If you don't use such system you will go over system limits very rapidly.