Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <B7C08D4D-9622-4859-A028-C2C2B713D1D1@apache.org>
References: 
 <CACLy94XiKgjsZibTn5Mb5GKByH-3=yH5t-yOd+Ez_A+Dp3buaA@mail.gmail.com>
	<CAHdjipKB_DkkJnhUvTNQd58a5xuAm6zCHifdpTCmyrRewSAjfQ@mail.gmail.com>
	<CACLy94VFt-qXGTWXBvAWMw-TrPYsmrDeaovaQwCX5GCtppKDZQ@mail.gmail.com>
	<278988D5-8E9C-46C0-BD39-A1AA28C6B15D@sri.com>
	<CACLy94WttB2ye3WEf2qKv6R3fMH=DCHigkwDQUzayvS_Mg7pNA@mail.gmail.com>
	<CAKmKYaCL2gtyh1XfW4g1YYjBKv44eE0+50-gysHjUZfyeKEs+A@mail.gmail.com>
	<CACLy94VJZ53ywoh+suf1+ThnS1oPgwFAzzQVrEKtiW7cE_zhhw@mail.gmail.com>
	<CAKmKYaDw75xPO99=ubc-hnTh=Kfj+Tc+N2y8iujzz5NOFbqdtA@mail.gmail.com>
	<CACLy94Wzpdnz35gFN+ZKhBAR4SeigE3KFC=q0sX=zBPZ11offA@mail.gmail.com>
	<CAD2UGCXgOjmKvTLJFrQjhu5f675Lm10+WMBN-cn0kdMP=5-JaA@mail.gmail.com>
	<CAKmKYaC+SunbVou4avmt0kZZCENakRYt0bLs6R9-91ZesAcF8Q@mail.gmail.com>
	<CACLy94VwvLxQhuOr-3e=0HRxs5wtHDUpSnOo6Hh1JObgOEUA0w@mail.gmail.com>
	<B7C08D4D-9622-4859-A028-C2C2B713D1D1@apache.org>
Date: Tue, 30 Jul 2013 11:52:57 +0100
Message-ID: 
 <CAD2UGCVTrGbhT76s879nV3W+CNs9se5M5SHe3yrpczz0RfNpFg@mail.gmail.com>
Subject: Re: Persona and BrowserID integration
From: Dale Harvey <dale@arandomurl.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001a11c3a94c70dabb04e2b8693c

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

> Dale, what do you think about the value of "official" Persona support
> in CouchDB, versus the possibility that it becomes a plugin "killer
> app" or at least a decent reference implementation?

Are you asking whether I think it should be always be in core vs being a
plugin? or should we have some 'blessed' official plugins vs wild west.

In terms of being in core I think its one of various auth options, but its
not so much a value judgement and more that it can be a plugin, and I think
if it can be a plugin it should be, nothing to do with how useful it is, as
said I love browser_id and will be installing it on every instance I run
but I am worried about the fact that every thing we add to core adds more
work in terms of agreeing details about implementation, support for an ever
growing api, artificial release delays and other problems, I want to see
this type of functionality available to users (me) when you write it.

As for 'blessed plugins' vs wild west, I can see it useful to having a set
of maintained plugins that are testing with each release and signified as
such, not sure its absolutely required though, and I do think installing
arbitrary plugins needs to be possible.

Yeh given that a one click plugin system is fairly ambitious and this
plugin has been around for ages, I think its reasonable to merge it before
the plugin system is ready, but doing it with the goal of removing it to a
plugin and using it to think about the implications / api and coming up
with a plugin plan I think is useful


On 29 July 2013 18:01, Jan Lehnardt <jan@apache.org> wrote:

>
> On Jul 29, 2013, at 18:29 , Jason Smith <jhs@apache.org> wrote:
>
> >
> > On Mon, Jul 29, 2013 at 11:24 PM, Dirkjan Ochtman <dirkjan@ochtman.nl>
> wrote:
> >> On Mon, Jul 29, 2013 at 5:24 PM, Dale Harvey <dale@arandomurl.com>
> wrote:
> >>> On the topic of browser_id support in CouchDB, it feels like this is =
a
> big
> >>> chance to push for usable plugins, should the aim for this not to be
> >>> included into core but to be available as a one click install from
> >>> futon/fauxton (this and geocouch seem prime candidates)?
> >>
> >> Yeah, I think that would be good. For me, the primary motivation would
> >> be that CouchDB shouldn't grow a kitchen sink.
>
> +1
>
>
> >> On the other hand, one click installs from F(u|aux)ton sounds kind of
> ambitious!
>
> Oh yes, and so worth it :)
>
>
> > Given how old this plugin is (it came out right after BrowserID was
> > announced IIRC), I kind of want to merge it in, then refactor it out
> > if/when plugins improve.
>
> I want plugins badly, but let=92s not block this one from landing in mast=
er
> for an imaginary plugin system.
>
> That said, I hope that minimal changes are required for modules under
> `src/` to become plugins later. Let=92s get to that bridge before we cros=
s
> it.
>
> That said, I am making plugins my priority in the next few weeks.
>
> Jan
> --
>
>
>

--001a11c3a94c70dabb04e2b8693c--