couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: CouchDB Plugins First Draft
Date Thu, 01 Nov 2012 11:44:52 GMT

On Nov 1, 2012, at 07:49 , Benoit Chesneau <> wrote:

> On Wed, Oct 31, 2012 at 11:28 PM, Alexander Shorin <> wrote:
>> Hi Jan.
>> More detailed and explained question from IRC meeting.
>> Why there is need to reinvent own package manager when most modern
>> systems (even Windows) already has package manager?
>> What problem tried to be solved?
>> ------------------------------------------------------------
>> Easy find, install and activate any CouchDB plugin in one-shot action,
>> right? Following example from gist:
>> $ cpm # couch plugin manager
>> $ cpm search geocouch
>> $ cpm install geocouch
>> While it tries to simplify extending of CouchDB, it brings a lot of
>> problems into system
>> What problems cpm brings?
>> -----------------------------------------------------
>> 1. Dependencies.
>> While any system package already able to resolve dependencies,
>> conflicts, provide slots for different versions, cpm will need to
>> reimplement this features. Geocouch isn't good example, next one is
>> much better:
>> $ cpm install couchdb-lucene # what about dependencies?
>> I don't think (and hope it will not) that this command will install
>> JRE and other java things into my system while I'm only expects this
>> plugin. System package managers already know what need and which
>> versions of to properly install lucene. Should this `cpm install`
>> command only check for suitable environment before landing? Or may be
>> cpm will know how to cooperate with system package managers to propose
>> install required dependencies?
>> 2. Namespace.
>> Since CouchDB installs system-wide (most cases) should plugins be
>> installed in same way? Or each user may have his own set of active
>> plugins? But it looks like that only CouchDB admin may operate with
>> plugins from Futon, so plugins have to live at least by path
>> accessiable for couchdb user. So there couldn't be personalised
>> plugins and npm system wouldn't work. So, cpm utility is only useful
>> for root user which is already has access to system package manager.
>> 3. BigCouch
>> How plugins system proposed to be work after BigCouch merge? Would
>> plugins be installed for all shards or only just for current one? Will
>> cluster works right if some shards would have geocouch-1.0, some of
>> them has geocouch-1.3 with breaking changes and for others it just
>> missed?
>> Why system package manager?
>> ---------------------------------------------------------
>> $ flaggie dev-db/couchdb +lucene # or echo "dev-db/couchdb lucene" >>
>> /etc/portage/package.use
>> $ emerge couchdb
>> And we'd got CouchDB with couchdb-lucene plugin and handled all
>> required dependencies. Now system takes care about packages
>> consistency and we're always sure and accidental iceadtea uninstall
>> would be passed silently since it have to break our couchdb-lucene
>> extension.
>> In same way other projects are already have implemented their
>> "plugins" system: nginx, php. Yes, they have not plugins, but modules,
>> but since they acts on system level there is no easy and secure way to
>> let everyone enable/disable/install any thirdparty component and this
>> way is the right one.
>> Following RabbitMQ project, they ships with all main plugins on board
>> - you need just to enable with through cli utility. If you need to
>> install some third party plugin, just copy his directory to rabbits
>> plugins one. But to be honest, RabbitMQ plugin manager tool doesn't
>> tries to act as package manager: it only shows, enables and disables
>> plugins, nothing more - that's why their approach works fine.
>> So I've smoothly went from original question to set of other ones, but
>> I suppose they are also interested to be answered since they are
>> defined show cpm will work and handle plugins.
>> P.S. Sorry for poorly mind dump style, 2:40 am there. I could try to
>> explain something in other way if it wasn't clear enough...
>> --
>> ,,,^..^,,,
>> On Mon, Oct 29, 2012 at 8:41 PM, Jan Lehnardt <> wrote:
>>> Hey all,
>>> during one of the past IRC Meetings I promised to write up
>>> what I have in mind for a CouchDB Plugin System.
>>> Here is my first draft:
>>> This is very early stage, but I wanted to get the idea out
>>> of the door. If anyone feels compelled to go into further
>>> detail, or even implement some of this, more power to you!
>>> Note: This is especially interesting for the non-Erlang
>>> folks here that need an excuse to contribute :)
>>> For the frontend, we’d need some mockups on how the Futon
>>> interaction would work (that is regardless of the state
>>> of Futon.Current and Futon.Next).
>>> On the backend, you could start figuring out what the
>>> registry could look like.
>>> I’m looking forward to your feedback!
>>> Cheers!
>>> Jan
>>> --
> I second that , we need to find a good way to handle plugin.  I think we
> have 4 cases to solve reading the gist:
> 1. upload from the HTTP api an Erlang plugin.
> 2. install a couchapp via HTPP
> 3. install an erlang plugin  from the fs
> 4. install a couchapp from the fs
> Both 2 & 4 can be easily handled today. Though it raises
> some interesting problems:
> - how to allow a user to push a couchapp
> - how to make sure that the couchapp can have access to a specific db on
> the node and the cluster.
> 1 & 3 have some other questions:
> - how is done the build? Is the plugin sent as a binary or is build on the
> target machine?
> - how to fix dependencies ? In that case , the requirements are generally
> started when the plugin start and simply fail if the requirement isn't
> found. This is what do elasticsearch or rabbitmq for ex.
> - What if a plugin is installed while the node is running ? Should we
> handle hot upgrade?
> - What happen when the plugin is unloaded or unregistered. Especially if it
> depends on some dependencies.
> - sandboxing. How to make sure a "native" plugin won't do bad things on my
> system
> - how to deploy the plugin on a cluster?
> Imo we should have a look on how it's handled in the mobiles right now:
> - get an app from a location
> - check it's security properties
> - check requirements
> - ask to the authorized users if the app can have access to a db/resource
> ...
> But, hat if we distinct backend plusgins in erlang from the other. In my
> understanding we need both to extend internals of couchdb. But maybe we can
> find to another system allowing us to extend couchdb. Such plugin could be
> then written in javascript, lua, elixir ... And could be sandboxed.
> This is actually something I am working on and I will release preliminary
> work at the end of the week or smth like it but in short the idea I have is
> to extend the couchapp system for internal couchapps which are executed in
> couchdb instead of the browser and have access to the full api. Networks
> access & disk are limited  except if specifically allowed. Using such
> features allows :
> - installation and upgrade via HTTP
> - plugin replication: you don't have to install cheff, puppet... plugins
> are contained in a doc and can be replicated like others.
> - the security system of the frontend couchapps could be reused
> Anyway I quite like the description of plugins described by jan  and I am
> happy to help on that .

> Btw why not using the wiki instead of github to
> handle the spec writing?

Because I wanted a forum where commenting was easy for the first stab at this.
I fully intend to move this to the wiki once it becomes a little more material.
This was purely a high-level request for comments. I hope that’s okay.


View raw message