[
https://issues.apache.org/jira/browse/COUCHDB-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987701#action_12987701
]
Paul Joseph Davis commented on COUCHDB-1046:
--------------------------------------------
Reading through the docs there are some scary bits here:
On the code path cache:
"To activate it, start the emulator with the command line flag -code_path_cache
or call code:rehash(). When the cache is created (or updated), the code server
searches for modules in the code path directories. This may take some time if
the the code path is long."
Then there's the section on new vs old code that we're all familiar with from
the config with exported functions and what not that's also important to
consider.
I see your point about what type of daemon that's started isn't configurable as
of yet, but I think it'd be better to approach this from the point of view of
loading a set of services that includes the rest of CouchDB rather than having
lots of other bits.
I'm also not reading too thoroughly, but restarting all secondary services when
any one of them changes seems like not a good idea.
As to the code paths and $PREFIX/couchdb/erlang/lib thing, I think you're
missing a step when you say "add a plugin via the HTTP interface" because you
still have to put the actual code on the machine. Rather than letting people
put code all over the filesystem and then make us have to deal with dynamically
changing code paths, I'd still much prefer having a single place that people
can put code (or perhaps a list of places that is also configurable for
packagers).
I don't see this as too onerous either. Someone had to do "cp my_app/
/random/path/to/my_app" so there's no reason they can't do "cp my_app
`pkg-config --variable=erl_libs`".
Or in other words, this looks on the outside like its a trivial patch but my
instincts are telling me that this direction is going to turn into a mess of
edge conditions and crazy behavior that we can't predict. The goals I think are
good, but I think we should look for a simpler solution that's more consistent
across all of couch.
> 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-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.
