Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAHdjipK3UOg3FbnA_sGUpcP8YXOa0PYfnn3Zx0JmTodPjJdu+A@mail.gmail.com>
References: <40BCC84F-C695-492E-B56E-08C60955A3D8@apache.org>
	<CAHdjipK3UOg3FbnA_sGUpcP8YXOa0PYfnn3Zx0JmTodPjJdu+A@mail.gmail.com>
Date: Wed, 31 Oct 2012 23:40:40 +0000
Message-ID: 
 <CABvT1DFAcMQtx4WGBPwZwqRkNzVBFPCnFb_djirDtS_9RFJsFw@mail.gmail.com>
Subject: Re: CouchDB Plugins First Draft
From: Robert Newson <rnewson@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=047d7b2e76e030521f04cd636e45

--047d7b2e76e030521f04cd636e45
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I quite like the rabbitmq approach (a lot like the apache httpd approach).
you can enable/disable/list plugins but the tool doesn't include the
downloading and managed repository bits, which is a huge rabbit hole (pun
intended).


On 31 October 2012 22:28, Alexander Shorin <kxepal@gmail.com> 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 <jan@apache.org> 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:
> >
> >   https://gist.github.com/3974676
> >
> > 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=92d 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=92m looking forward to your feedback!
> >
> > Cheers!
> > Jan
> > --
> >
>

--047d7b2e76e030521f04cd636e45--