[
https://issues.apache.org/jira/browse/COUCHDB-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987795#action_12987795
]
Benoit Chesneau commented on COUCHDB-1046:
------------------------------------------
On Thu, Jan 27, 2011 at 10:46 PM, Paul Joseph Davis (JIRA)
> 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)
application with same name are loaded only once.
why do we care about that ? It will create an error, the dev will
solve it or no.
application with same name are loaded only once. So that can't happen.
One thing I forgot though is to add to the loaded apps the couchdb
apps. I will add that
plugins are all reloaded. How can that happen if deps are managed per
plugins ? Not sure to follow
What do you mean ?
No, the dev knows.
> 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).
what do you mean ? not sure to follow on this one
He make sure to delete old one ? Or we can check app versioning and
remove old one. Maybe that's better but even erlang don't manage it so
well.
It will create an error. But appart the fact that the error should
be understandable we can't do much about it. I will had a mean to
manage error display in this case.
Since modules are loaded by applications it shouldn't be a problem
I think. The same happen with rebar maybe we could discuss with the
author about that.
Totally agree. It's totally clear for me too that we need something
enough simple but robust if we want to support a plugin system. On the
other hand we can't do more than erlang can do :)
- benoît
> 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.
