Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.0
    • Component/s: None
    • Labels:
      None

      Description

      It should be easy to install CouchDB plugins.

        Activity

        Hide
        Jason Smith added a comment -

        Yes, I have a common install of CouchDB with all its plugins, and I choose which to enable when spinning up an instance. (Multiple instances can run on a machine, on different ports, and from different config files.) Part of the config is generated dynamically when a couch starts. So long story short, I am fine with anything, just providing some background about the odd-looking blacklist feature.

        Okay, that is good advice about going too far with OTP. Thanks. Yes, CouchDB follows the "NoTP" architecture.

        I think I have found a good middle ground, using Rebar to create and build a full-featured but no-op CouchDB plugin. I have a rebar template working which generates the kind of plugin that CouchDB currently supports. I am now investigating perhaps a simple rebar plugin which will automate zipping the CouchDB plugin. I am unsure if that will pay out though. I will email the list when I am done.

        Considering its near-zero real-world exercise, the .ini system is decent for adding modular functionality. However I see three problems:

        1. If you want to change functionality of an existing path (e.g. /_utils) then you must completely override the normal handler, and then manually call it from your code. For example, futon_couchdb serves Mobile Futon to mobile browsers. It is a simple user-agent check. For desktop browsers, I have to manually call the original Futon handler. That is hard coded in the plugin. So if you reconfigured to some other Futon, and also installed my plugin, then bizarrely, you would get standard Futon.

        2. In general, the order plugins are loaded is very significant. The last http handler to register for a particular URL wins.

        3. Standard stuff. It is early days so there are not many interesting or convenient hooks into interesting situations within Couch. I am currently working on a custom logger and I think it will require a minor change to CouchDB core. I just want standard NCSA common log format for chrissakes!

        Show
        Jason Smith added a comment - Yes, I have a common install of CouchDB with all its plugins, and I choose which to enable when spinning up an instance. (Multiple instances can run on a machine, on different ports, and from different config files.) Part of the config is generated dynamically when a couch starts. So long story short, I am fine with anything, just providing some background about the odd-looking blacklist feature. Okay, that is good advice about going too far with OTP. Thanks. Yes, CouchDB follows the "NoTP" architecture. I think I have found a good middle ground, using Rebar to create and build a full-featured but no-op CouchDB plugin. I have a rebar template working which generates the kind of plugin that CouchDB currently supports. I am now investigating perhaps a simple rebar plugin which will automate zipping the CouchDB plugin. I am unsure if that will pay out though. I will email the list when I am done. Considering its near-zero real-world exercise, the .ini system is decent for adding modular functionality. However I see three problems: 1. If you want to change functionality of an existing path (e.g. /_utils) then you must completely override the normal handler, and then manually call it from your code. For example, futon_couchdb serves Mobile Futon to mobile browsers. It is a simple user-agent check. For desktop browsers, I have to manually call the original Futon handler. That is hard coded in the plugin. So if you reconfigured to some other Futon, and also installed my plugin, then bizarrely, you would get standard Futon. 2. In general, the order plugins are loaded is very significant. The last http handler to register for a particular URL wins. 3. Standard stuff. It is early days so there are not many interesting or convenient hooks into interesting situations within Couch. I am currently working on a custom logger and I think it will require a minor change to CouchDB core. I just want standard NCSA common log format for chrissakes!
        Hide
        Bob Ippolito added a comment -

        By "without having to change the files" do you also mean "I need to do this
        with an environment variable and not a configuration file"?

        Personally, I think that plugins are the wrong place to start to try and
        OTP-ify CouchDB. OTP also doesn't have a concept of plugins, in the OTP
        world the release should be a self-contained application, so you're going
        to be coming up with weird conventions no matter what you try and do.

        Show
        Bob Ippolito added a comment - By "without having to change the files" do you also mean "I need to do this with an environment variable and not a configuration file"? Personally, I think that plugins are the wrong place to start to try and OTP-ify CouchDB. OTP also doesn't have a concept of plugins, in the OTP world the release should be a self-contained application, so you're going to be coming up with weird conventions no matter what you try and do.
        Hide
        Jason Smith added a comment -

        Sure. As long as I can enable/disable plugins at start time, without having to change the files installed on the filesystem, I am happy.

        Bob (or anybody), how familiar are you with official or at least traditional Erlang software deployment? Do you have any thoughts about using the Erlang releases, or upgrade packages, or appup files for plugin development? Basically I would like to cut with the grain of whatever practices are already done or recommended by the Erlang community.

        For example, suppose a plugin author built a plugin as an Erlang application, then cut a release, and somehow fed that to CouchDB. Does that strike anybody as a plausible avenue?

        Show
        Jason Smith added a comment - Sure. As long as I can enable/disable plugins at start time, without having to change the files installed on the filesystem, I am happy. Bob (or anybody), how familiar are you with official or at least traditional Erlang software deployment? Do you have any thoughts about using the Erlang releases, or upgrade packages, or appup files for plugin development? Basically I would like to cut with the grain of whatever practices are already done or recommended by the Erlang community. For example, suppose a plugin author built a plugin as an Erlang application, then cut a release, and somehow fed that to CouchDB. Does that strike anybody as a plausible avenue?
        Hide
        Bob Ippolito added a comment -

        Sounds like a good case for having a whitelist in the config and removing
        the blacklist stuff.

        Show
        Bob Ippolito added a comment - Sounds like a good case for having a whitelist in the config and removing the blacklist stuff.
        Hide
        Jason Smith added a comment -

        The blacklist exists so you can specify which plugins to load at run time rather than at build time.

        In other words, simply placing a plugin in that directory activates the plugin; but what if you want to disable the plugin? Worse, what if you run multiple instances of CouchDB on the same machine, from the same installation?

        Iris Couch has a plugin, cgi_couchdb, where you can put CGI scripts in your design document, and run arbitrary CGI applications in CouchDB. Obviously that is only enabled for trusted users.

        If there was a way to activate/deactivate plugins from the config, I would be happy to see the blacklist go. Mostly I implemented it this way because my Bash-fu was stronger than my Erlang-fu at the time.

        Show
        Jason Smith added a comment - The blacklist exists so you can specify which plugins to load at run time rather than at build time. In other words, simply placing a plugin in that directory activates the plugin; but what if you want to disable the plugin? Worse, what if you run multiple instances of CouchDB on the same machine, from the same installation? Iris Couch has a plugin, cgi_couchdb, where you can put CGI scripts in your design document, and run arbitrary CGI applications in CouchDB. Obviously that is only enabled for trusted users. If there was a way to activate/deactivate plugins from the config, I would be happy to see the blacklist go. Mostly I implemented it this way because my Bash-fu was stronger than my Erlang-fu at the time.
        Hide
        Jan Lehnardt added a comment -
        • Serve static web assets (for Futon/Fauxton) from `/_plugins/<name>/`.
        Show
        Jan Lehnardt added a comment - Serve static web assets (for Futon/Fauxton) from `/_plugins/<name>/`.
        Hide
        Jan Lehnardt added a comment -

        And some more:

        • only install a plugin if the source and target CouchDB version matches.

        This concludes my MVP phase.

        Show
        Jan Lehnardt added a comment - And some more: only install a plugin if the source and target CouchDB version matches. This concludes my MVP phase.
        Hide
        Jan Lehnardt added a comment -

        +1 on the lib/plugins destination, that’s what the code does now.

        I suggest we nuke the blacklist stuff.

        I made a note to investigate a `couchdb --aditional-plugin-dir` option for specifying distro-installed plugins.

        • * *

        A few more updates:

        • Added uninstall (incl. Futon)
        • Rebased against master.
        Show
        Jan Lehnardt added a comment - +1 on the lib/plugins destination, that’s what the code does now. I suggest we nuke the blacklist stuff. I made a note to investigate a `couchdb --aditional-plugin-dir` option for specifying distro-installed plugins. * * A few more updates: Added uninstall (incl. Futon) Rebased against master.
        Hide
        Bob Ippolito added a comment -

        As far as plugin installation goes, I think we should probably just put them in prefix/lib/couchdb/plugins/ (same location as the built-in support now) and have the convention to be to make this writeable by the couchdb user. /tmp is obviously not a real solution

        For distro-installed plugins, there could be another directory. Perhaps the boot script could allow you to specify more than one plugin directory for this purpose? I don't have a lot of insight into why linux distro packagers do what they do and how they want to do it.

        I think the "plugin blacklist" support could use a lot of work too. The way that grep is done is definitely not the right way to do it, and it should probably be in a file instead of (or in addition to) an undocumented environment variable. To be honest I'd rather put as much of this configuration stuff into Erlang and out of shell scripts as possible, but that would be a separate issue than this.

        Show
        Bob Ippolito added a comment - As far as plugin installation goes, I think we should probably just put them in prefix/lib/couchdb/plugins/ (same location as the built-in support now) and have the convention to be to make this writeable by the couchdb user. /tmp is obviously not a real solution For distro-installed plugins, there could be another directory. Perhaps the boot script could allow you to specify more than one plugin directory for this purpose? I don't have a lot of insight into why linux distro packagers do what they do and how they want to do it. I think the "plugin blacklist" support could use a lot of work too. The way that grep is done is definitely not the right way to do it, and it should probably be in a file instead of (or in addition to) an undocumented environment variable. To be honest I'd rather put as much of this configuration stuff into Erlang and out of shell scripts as possible, but that would be a separate issue than this.
        Hide
        Jan Lehnardt added a comment -

        And finally:

        Show
        Jan Lehnardt added a comment - And finally: added a Makefile with a `plugin` target to couchperuser: https://github.com/etrepum/couchperuser/pull/1 made a distribution and put it on p.a.o/~jan and added it to the plugins.html for ya’ll to install
        Hide
        Jan Lehnardt added a comment -

        I added the `-erl-bin` and `-erlang-versino` options to `couch-config` and updated my geocouch fork’s Makefile with the respective new infrastructure there.

        Show
        Jan Lehnardt added a comment - I added the `- erl-bin` and ` -erlang-versino` options to `couch-config` and updated my geocouch fork’s Makefile with the respective new infrastructure there.
        Hide
        Jan Lehnardt added a comment -

        Also updated my geocouch branch to use the new `priv/default.d` convention.

        Show
        Jan Lehnardt added a comment - Also updated my geocouch branch to use the new `priv/default.d` convention.
        Hide
        Jan Lehnardt added a comment -

        Thanks Bob Ippolito, I merged your `059935c53680ea72bdd2d1ffc3b1277f02d3fdd3` commit

        I’m happy to switch this to any other useful archive/zip format, when there are advantages, but yeah, I expect more, rather than less Erlang in the plugins.

        Show
        Jan Lehnardt added a comment - Thanks Bob Ippolito , I merged your `059935c53680ea72bdd2d1ffc3b1277f02d3fdd3` commit I’m happy to switch this to any other useful archive/zip format, when there are advantages, but yeah, I expect more, rather than less Erlang in the plugins.
        Hide
        Bob Ippolito added a comment -

        For reference, this is what I have been testing with: https://github.com/etrepum/couchperuser

        To build it, just make sure (the right) couch-config is on the PATH, or set ERL_LIBS appropriately before calling rebar compile. You can then symlink the couchperuser dir into $PREFIX/lib/couchdb/plugins (or tmp/plugins when using make dev).

        Using a zip file instead of tgz would be a bit more natural for plugin distribution. Erlang can actually work with code that's in zip files (this is how rebar works, for example. try unzip -l `which rebar`). See "Loading Code from Archive Files" at http://www.erlang.org/doc/man/code.html#id102475 for some implementation details of how ".ez" archives work. Loading configuration from these would be a little more complicated but not impossible (couch_config could recognize .ez files and pull priv/default.d/*.ini from them with zip:foldl/3). Note that this probably isn't a good idea for all plugins, since I assume that it will make sense to ship them with a bunch of data files in the future (e.g. html/js for admin tools).

        Show
        Bob Ippolito added a comment - For reference, this is what I have been testing with: https://github.com/etrepum/couchperuser To build it, just make sure (the right) couch-config is on the PATH, or set ERL_LIBS appropriately before calling rebar compile. You can then symlink the couchperuser dir into $PREFIX/lib/couchdb/plugins (or tmp/plugins when using make dev). Using a zip file instead of tgz would be a bit more natural for plugin distribution. Erlang can actually work with code that's in zip files (this is how rebar works, for example. try unzip -l `which rebar`). See "Loading Code from Archive Files" at http://www.erlang.org/doc/man/code.html#id102475 for some implementation details of how ".ez" archives work. Loading configuration from these would be a little more complicated but not impossible (couch_config could recognize .ez files and pull priv/default.d/*.ini from them with zip:foldl/3). Note that this probably isn't a good idea for all plugins, since I assume that it will make sense to ship them with a bunch of data files in the future (e.g. html/js for admin tools).
        Hide
        Bob Ippolito added a comment -

        So I didn't test your /tmp plugin downloader stuff, but I have the startup code using priv/default.d/*.ini files from plugins that are installed to $PREFIX/lib/couchdb/plugins. Also fixed a few automake related bugs. See https://github.com/etrepum/couchdb/commit/059935c53680ea72bdd2d1ffc3b1277f02d3fdd3

        Show
        Bob Ippolito added a comment - So I didn't test your /tmp plugin downloader stuff, but I have the startup code using priv/default.d/*.ini files from plugins that are installed to $PREFIX/lib/couchdb/plugins. Also fixed a few automake related bugs. See https://github.com/etrepum/couchdb/commit/059935c53680ea72bdd2d1ffc3b1277f02d3fdd3
        Hide
        Bob Ippolito added a comment -

        I think that ini files should be used instead of erlt, and plugins should have a priv/default.d directory that is automatically used on startup. I'm crafting a patch (on top of this branch) that I'll push to github in the next day or so for you to look at.

        Show
        Bob Ippolito added a comment - I think that ini files should be used instead of erlt, and plugins should have a priv/default.d directory that is automatically used on startup. I'm crafting a patch (on top of this branch) that I'll push to github in the next day or so for you to look at.
        Hide
        Jan Lehnardt added a comment - - edited

        (note, this is a copy of README.md in the source, refer to there (https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=src/couch_plugins/README.md;hb=refs/heads/1867-feature-plugins / https://github.com/janl/couchdb/blob/1867-feature-plugins/src/couch_plugins/README.md for a more up-to-date version)

        Heya,

        I couldn’t help myself thinking about plugin stuff and ended up
        whipping up a proof of concept.

        Here’s a <1 minute demo video:

        https://dl.dropboxusercontent.com/u/82149/couchdb-plugins-demo.mov

        Alternative encoding:

        https://dl.dropboxusercontent.com/u/82149/couchdb-plugins-demo.m4v)

        In my head the whole plugin idea is a very wide area, but I was so
        intrigued by the idea of getting something running with a click on a
        button in Futon. So I looked for a minimally viable plugin system.

        Design principles

        It took me a day to put this all together and this was only possible
        because I took a lot of shortcuts. I believe they are all viable for a
        first iteration of a plugins system:

        1. Install with one click on a button in Futon (or HTTP call)
        2. Only pure Erlang plugins are allowed.
        3. The plugin author must provide a binary package for each Erlang (and,
        later, each CouchDB version).
        4. Complete trust-based system. You trust me to not do any nasty things
        when you click on the install button. No crypto, no nothing. Only
        people who can commit to Futon can release new versions of plugins.
        5. Minimal user-friendlyness: won’t install plugins that don’t match
        the current Erlang version, gives semi-sensible error messages
        (wrapped in a HTTP 500 response
        6. Require a pretty strict format for binary releases.

        Roadmap

        Here’s a list of things this first iterations does and doesn’t do:

        • Pure Erlang plugins only. No C-dependencies, no JavaScript, no nothing.
        • No C-dependencies.
        • Install a plugin via Futon (or HTTP call). Admin only.
        • A hardcoded list of plugins in Futon.
        • Loads a pre-packaged, pre-compiled .tar.gz file from a URL.
        • Only installs if Erlang version matches.
        • No security checking of binaries.
        • No identity checking of binaries.

        Here are a few things I want to add before I call it MVP*:

        • Uninstall a plugin via Futon (or HTTP call). Admin only.
        • Only installs if CouchDB version matches.
        • Binaries must be published on *.apache.org.
        • Register installed plugins in the config system.
        • Make sure plugins start with the next restart of CouchDB.
        • Show when a particular plugin is installed.

        *MVP hopefully means you agree we can ship this with a few warnings
        so people can get a hang of it.

        Here is a rough list of features squared against future milestones:

        Milestone 2: Be creator friendly

        • Make it easy to build a CouchDB plugin by providing one or more easy
          to start templates.
        • Make it easy to publish new plugins and new versions of existing plugins.
        • Make it easy to supply packages for multiple Erlang & CouchDB versions.

        Milestone 3: Public registry

        • Instead of hardcoding a list of plugins into Futon/Fauxton, we load
          a list of applicable plugins from a central (and configurable)
          plugins repository.
        • This allows plugin authors to publish new plugins and new versions
          of existing plugins independently.

        Milestone 4: Other Languages

        • Figure out how to handle C-dependencies for Erlang plugins.
        • Figure out how to allow other language plugins
          (c.f. non-JS query servers)

        Milestone X: Later

        • Add some account/identity/maybe crypto-web-of-trust system for
          authors to publish “legit” plugins.
        • Sign & verify individual releases.

        A few more things that can happen concurrently depending on what
        plugins require:

        • Integrate Erlang/JS tests in the installation
        • Integrate docs

        How it works

        This plugin system lives in `src/couch_plugins` and is a tiny CouchDB
        module.

        It exposes one new API endpoint `/_plugins` that an admin user can
        POST to.

        The additional Futon page lives at /_utils/plugins.html it is
        hardcoded.

        Futon (or you) post an object to `/_plugins` with four properties:

        {
        "name": "geocouch", // name of the plugin, must be unique
        "url": "http://people.apache.org/~jan", // “base URL” for plugin releases (see below)
        "version": "couchdb1.2.x_v0.3.0-11-g4ea0bea", // whatever version internal to the plugin
        "checksums":

        { "R15B03": "ZetgdHj2bY2w37buulWVf3USOZs=" // base64’d sha hash over the binary }

        }

        `couch_plugins` then attempts to download a .tar.gz from this
        location:

        http://people.apache.org/~jan/geocouch-couchdb1.2.x_v0.3.0-12-g4ea0bea-R15B03.tar.gz

        It should be obvious how the URL is constructed from the POST data.
        (This url is live, feel free to play around with this tarball).

        Next it calculates the sha hash for the downloaded .tar.gz file and
        matches it against the correct version in the `checksums` parameter.

        If that succeeds, we unpack the .tar.gz file (currently in `/tmp`,
        need to find a better place for this) and adds the extracted directory
        to the Erlang code path
        (`code:add_path("/tmp/couchdb_plugins/geocouch-couchdb1.2.x_v0.3.0-12-g4ea0bea-R15B03/ebin")`)
        and loads the included application (`application:load(geocouch)`).

        Then it looks into the `./config` directory that lives next to `ebin/`
        in the plugin directory for a file `config.erlt` (“erl-terms”). with a
        list of configuration parameters to load. We parse the file and set
        the config directives one by one.

        If that all goes to plan, we report success back to the HTTP caller.

        That’s it!

        It’s deceptively simple, probably does a few things very wrong and
        leaves a few things open (see above).

        One open question I’d like an answer for is finding a good location to
        unpack & install the plugin files that isn’t `tmp`. If the answer is
        different for a pre-BigCouch/rcouch-merge and post-BigCouch/rcouch-
        merge world, I’d love to know

        Code

        The main branch for this is 1867-feature-plugins:

        ASF: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=refs/heads/1867-feature-plugins
        GitHub: https://github.com/janl/couchdb/compare/apache:master...1867-feature-plugins

        I created a branch on GeoCouch that adds a few lines to its `Makefile`
        that shows how a binary package is built:

        https://github.com/janl/geocouch/compare/couchbase:couchdb1.3.x...couchdb1.3.x-plugins

        Build

        Build CouchDB as usual:

        ./bootstrap
        ./configure
        make
        make dev
        ./utils/run

        • * *

        I hope you like this Please comment and improve heavily!

        Let me know if you have any questions

        If you have any criticism, please phrase it in a way that we can use
        to improve this, thanks!

        Best,
        Jan

        Show
        Jan Lehnardt added a comment - - edited (note, this is a copy of README.md in the source, refer to there ( https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=src/couch_plugins/README.md;hb=refs/heads/1867-feature-plugins / https://github.com/janl/couchdb/blob/1867-feature-plugins/src/couch_plugins/README.md for a more up-to-date version) Heya, I couldn’t help myself thinking about plugin stuff and ended up whipping up a proof of concept. Here’s a <1 minute demo video: https://dl.dropboxusercontent.com/u/82149/couchdb-plugins-demo.mov Alternative encoding: https://dl.dropboxusercontent.com/u/82149/couchdb-plugins-demo.m4v ) In my head the whole plugin idea is a very wide area, but I was so intrigued by the idea of getting something running with a click on a button in Futon. So I looked for a minimally viable plugin system. Design principles It took me a day to put this all together and this was only possible because I took a lot of shortcuts. I believe they are all viable for a first iteration of a plugins system: 1. Install with one click on a button in Futon (or HTTP call) 2. Only pure Erlang plugins are allowed. 3. The plugin author must provide a binary package for each Erlang (and, later, each CouchDB version). 4. Complete trust-based system. You trust me to not do any nasty things when you click on the install button. No crypto, no nothing. Only people who can commit to Futon can release new versions of plugins. 5. Minimal user-friendlyness: won’t install plugins that don’t match the current Erlang version, gives semi-sensible error messages (wrapped in a HTTP 500 response 6. Require a pretty strict format for binary releases. Roadmap Here’s a list of things this first iterations does and doesn’t do: Pure Erlang plugins only. No C-dependencies, no JavaScript, no nothing. No C-dependencies. Install a plugin via Futon (or HTTP call). Admin only. A hardcoded list of plugins in Futon. Loads a pre-packaged, pre-compiled .tar.gz file from a URL. Only installs if Erlang version matches. No security checking of binaries. No identity checking of binaries. Here are a few things I want to add before I call it MVP*: Uninstall a plugin via Futon (or HTTP call). Admin only. Only installs if CouchDB version matches. Binaries must be published on *.apache.org. Register installed plugins in the config system. Make sure plugins start with the next restart of CouchDB. Show when a particular plugin is installed. *MVP hopefully means you agree we can ship this with a few warnings so people can get a hang of it. Here is a rough list of features squared against future milestones: Milestone 2: Be creator friendly Make it easy to build a CouchDB plugin by providing one or more easy to start templates. Make it easy to publish new plugins and new versions of existing plugins. Make it easy to supply packages for multiple Erlang & CouchDB versions. Milestone 3: Public registry Instead of hardcoding a list of plugins into Futon/Fauxton, we load a list of applicable plugins from a central (and configurable) plugins repository. This allows plugin authors to publish new plugins and new versions of existing plugins independently. Milestone 4: Other Languages Figure out how to handle C-dependencies for Erlang plugins. Figure out how to allow other language plugins (c.f. non-JS query servers) Milestone X: Later Add some account/identity/maybe crypto-web-of-trust system for authors to publish “legit” plugins. Sign & verify individual releases. A few more things that can happen concurrently depending on what plugins require: Integrate Erlang/JS tests in the installation Integrate docs How it works This plugin system lives in `src/couch_plugins` and is a tiny CouchDB module. It exposes one new API endpoint `/_plugins` that an admin user can POST to. The additional Futon page lives at /_utils/plugins.html it is hardcoded. Futon (or you) post an object to `/_plugins` with four properties: { "name": "geocouch", // name of the plugin, must be unique "url": "http://people.apache.org/~jan", // “base URL” for plugin releases (see below) "version": "couchdb1.2.x_v0.3.0-11-g4ea0bea", // whatever version internal to the plugin "checksums": { "R15B03": "ZetgdHj2bY2w37buulWVf3USOZs=" // base64’d sha hash over the binary } } `couch_plugins` then attempts to download a .tar.gz from this location: http://people.apache.org/~jan/geocouch-couchdb1.2.x_v0.3.0-12-g4ea0bea-R15B03.tar.gz It should be obvious how the URL is constructed from the POST data. (This url is live, feel free to play around with this tarball). Next it calculates the sha hash for the downloaded .tar.gz file and matches it against the correct version in the `checksums` parameter. If that succeeds, we unpack the .tar.gz file (currently in `/tmp`, need to find a better place for this) and adds the extracted directory to the Erlang code path (`code:add_path("/tmp/couchdb_plugins/geocouch-couchdb1.2.x_v0.3.0-12-g4ea0bea-R15B03/ebin")`) and loads the included application (`application:load(geocouch)`). Then it looks into the `./config` directory that lives next to `ebin/` in the plugin directory for a file `config.erlt` (“erl-terms”). with a list of configuration parameters to load. We parse the file and set the config directives one by one. If that all goes to plan, we report success back to the HTTP caller. That’s it! It’s deceptively simple, probably does a few things very wrong and leaves a few things open (see above). One open question I’d like an answer for is finding a good location to unpack & install the plugin files that isn’t `tmp`. If the answer is different for a pre-BigCouch/rcouch-merge and post-BigCouch/rcouch- merge world, I’d love to know Code The main branch for this is 1867-feature-plugins: ASF: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=refs/heads/1867-feature-plugins GitHub: https://github.com/janl/couchdb/compare/apache:master...1867-feature-plugins I created a branch on GeoCouch that adds a few lines to its `Makefile` that shows how a binary package is built: https://github.com/janl/geocouch/compare/couchbase:couchdb1.3.x...couchdb1.3.x-plugins Build Build CouchDB as usual: ./bootstrap ./configure make make dev ./utils/run * * I hope you like this Please comment and improve heavily! Let me know if you have any questions If you have any criticism, please phrase it in a way that we can use to improve this, thanks! Best, Jan –

          People

          • Assignee:
            Jan Lehnardt
            Reporter:
            Jan Lehnardt
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development