Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of brian@streampunks.com
 designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
Sender: brian@streampunks.com
In-Reply-To: <C41798990E214888888840CAE1023FFF@gmail.com>
References: 
 <CAFVT+gCH__X+ycFqO79KY_mcn8DyqdYRJ-r54pBrLNL40quOiQ@mail.gmail.com>
	<511FEA90E28843239F62C7467F4A110A@cloudant.com>
	<C41798990E214888888840CAE1023FFF@gmail.com>
Date: Thu, 14 Nov 2013 14:15:52 -0500
Message-ID: 
 <CAFVT+gDcKgcwWjVC97mgn8O4=M+t7TRztZjF0XK2GsB2pYi4=Q@mail.gmail.com>
Subject: Re: Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
From: Brian Mitchell <brian@strmpnk.co>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 14, 2013 at 1:52 PM, till <klimpong@gmail.com> wrote:
>
>
> On Thursday 14 November 2013 at 18:28, Simon Metson wrote:
>
>> Hey,
>>
>> > > I agree, src/couch_plugins/README.md (http://README.md) has a quasi =
roadmap that I want to work
>> > > towards. The only edit for now would be that I=92d like a registry t=
hat can be
>> > > update independently from CouchDB releases. Would you be interested =
in helping
>> > > out with that? Or anything else around plugins?
>> > >
>> >
>> >
>> > I'm definitely interested to hear more. I'd love to help out with
>> > getting a common place for contributed couchdb things to be indexed
>> > and published. Plugins seem like an ideal testing ground. How do you
>> > imagine a plugin registry working?
>> >
>>
>>
>> I=92m interested in this too. Can we pick up stuff from npm?
>> Cheers
>> Simon
>>
>>
>
> Please don=92t. For starters, a more or less static registry would be awe=
some. Not databased.

I'm curious how static really avoids the database problem. Are you
saying it'd be better to just pull down a know good URL and that never
changes?

Beyond that, I'm not sure we need to use CouchDB just like NPM does
but it is pretty nice. Maybe fewer document mutations would help
(splitting plugin releases into their own documents could be a good
idea for those running local mirrors).

> Then minor nitpicks like:
>
>  - enforce semantic versions

+1. We should expect plugins to follow the same conventions that CouchDB do=
es.

>  - don=92t allow people to re-upload releases

Yes. We could avoid this partly by making releases more like immutable
documents.

>  - make it easy to mirror it

Replication is a natural fit here. There might be an argument for
allowing automated installation via plain-old-HTTP or filesystem
mirrors as well for the cases where people don't want to have to have
a separate database running just to setup their own CouchDB nodes with
private plugins (chicken-egg like situations emerge).

>  - some kind of signature for plugins/verification

+1.