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: 
 <CABvT1DFAcMQtx4WGBPwZwqRkNzVBFPCnFb_djirDtS_9RFJsFw@mail.gmail.com>
References: <40BCC84F-C695-492E-B56E-08C60955A3D8@apache.org>
	<CAHdjipK3UOg3FbnA_sGUpcP8YXOa0PYfnn3Zx0JmTodPjJdu+A@mail.gmail.com>
	<CABvT1DFAcMQtx4WGBPwZwqRkNzVBFPCnFb_djirDtS_9RFJsFw@mail.gmail.com>
Date: Wed, 31 Oct 2012 23:46:05 +0000
Message-ID: 
 <CABvT1DFnQeskwTnk10DA2=+0Qr6oGiKyk0aWqegymFG_=Vmdrw@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=bcaec517a99084a73b04cd6381bb

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

My only thought is how well (if at all) it fits into an OTP shape.


On 31 October 2012 23:40, Robert Newson <rnewson@apache.org> wrote:

> 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
>> > --
>> >
>>
>
>

--bcaec517a99084a73b04cd6381bb--