[
https://issues.apache.org/jira/browse/COUCHDB-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987778#action_12987778
]
Paul Joseph Davis commented on COUCHDB-1046:
--------------------------------------------
What happens when two plugins depend on the same erlang app?
What happens when two plugins depend on different versions of the same app?
What happens when two plugins depend on the same version, and after both are
loaded one of the two disappears?
What happens when its more than two?
What happens to NIF resources even if its the same version?
Is there a way for plugins to know that they don't need to include deps that
are included in CouchDB? (Thinking mochijson here)
Other questions that come to mind:
What happens when someone dumps a new plugin into the plugins directory?
What happens when someone adds a new version of a plugin to the directory?
What happens when someone deletes a loaded plugin?
What happens to code loading of modules like gen_server2 when its included in
many projects? (related to multiple dep versions above).
I'd like to be clear that I'm do want to make it super easy to have third party
code loaded into CouchDB but I'm very concerned that if we're not careful we're
going to walk into a tar pit of horribly complex systems that people are going
to expect us to fix/support properly. I'd much rather keep the whole thing as
super simple as possible so that we aren't held accountable for all the
possible weirdness.
> support load of external erlang modules in couchdb.
> ----------------------------------------------------
>
> Key: COUCHDB-1046
> URL: https://issues.apache.org/jira/browse/COUCHDB-1046
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core
> Reporter: Benoit Chesneau
> Fix For: 1.2
>
> Attachments: couchdb-plugins-003.patch, couchdb-plugins-004.patch,
> couchdb-plugins-01.patch, couchdb-plugins-02.patch
>
>
> If you want to add external modules in CouchDB and load them , you need to
> set the ERL_FLAGS environnement variable to the path of a module.
> The attached patch allows couchdb to load plugins from plugin key in couchdb
> section. It add needed path to the code path, so the vm can find modules.
> ex:
> [couchdb]
> plugins = plugin1, plugin2
> Each plugin can have its own section where it set the binaries patch,
> eventually if a service need to be added to the supervision you can set the
> module and function to load like in daemon section and tel if it's a
> supervisor or simple service.
> It also allows couchdb to load a plugin service (gen_server or such) to the
> supervision. You can choose if the service is a simple daemon or a supervisor.
> ex:
> [plugin1]
> code_path = /path/to/plugin1/ebin
> daemon = {module, function, [Args]}
> supervisor = false
> Let me know what you think about it. This patch is really useful here and
> allows me to dynamically load modules I want. Also it eases the integration
> of external module. For ex I can load my couchapp_ng modules with this lines
> in local.ini :
> [couchdb]
> plugins = couchapp-ng
> [couchapp-ng]
> code_path=/Users/benoitc/work/couchapp_ng/ebin
> daemon = {couchapp_ng_routes, start_link, []}
> [httpd_design_handlers]
> _app = {couchapp_ng_httpd, handle_app_req}
> [couchapp_ng_handlers]
> rewrite = {couchapp_ng_handlers, rewrite_handler}
> proxy = {couchapp_ng_handlers, proxy_handler}
> and can do the same with geocouch etc. Tested here with these modules.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
