From dev-return-28652-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Jul 30 10:53:48 2013
Return-Path:
X-Original-To: apmail-couchdb-dev-archive@www.apache.org
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id A3BC910CF2
for ; Tue, 30 Jul 2013 10:53:48 +0000 (UTC)
Received: (qmail 92676 invoked by uid 500); 30 Jul 2013 10:53:46 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 92615 invoked by uid 500); 30 Jul 2013 10:53:46 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 92602 invoked by uid 99); 30 Jul 2013 10:53:44 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jul 2013 10:53:44 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: apache.org
Received-SPF: error (nike.apache.org: local policy)
Received: from [209.85.212.46] (HELO mail-vb0-f46.google.com) (209.85.212.46)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jul 2013 10:53:39 +0000
Received: by mail-vb0-f46.google.com with SMTP id p13so1153670vbe.19
for ; Tue, 30 Jul 2013 03:52:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:x-gm-message-state;
bh=X5CI6AY1FKkOrkTVTeDMfDp3s2vkrCgEAQ6uEBDeMt4=;
b=bckf3iEMgZ3AVpnGxvN4ty7oCgsHMlR8IdDL70fO5ui6Ijs86wkxtJ9gn4XQIo9BFY
x57S7itpEKBDXfIkKsvbTx5EJnbZ2ukBhRrIAeHzl4zf/LpP0RiIct6M6Eiy6kJR5VMv
+p7Ym9CNDlHYiTTcY0RknQGFZI1tBnKMfIdX97lj6A97A4VEpDmgZ0wpsEjtyHdOk1u1
0El7D3HTc9DbXroGUwGiyHmCONjnQ7kXCXAX81Rann/j9vjPMUoTs9cjOjJ9N+LvgFoB
JxeyNSMRwhsgrKdRrPyld46EIJza76u0XphMePIGGr21pSRSKRlOO5VGR1Rs7H2wXwQm
i2Mg==
MIME-Version: 1.0
X-Received: by 10.220.162.200 with SMTP id w8mr9919474vcx.90.1375181577699;
Tue, 30 Jul 2013 03:52:57 -0700 (PDT)
Received: by 10.58.128.131 with HTTP; Tue, 30 Jul 2013 03:52:57 -0700 (PDT)
In-Reply-To:
References:
<278988D5-8E9C-46C0-BD39-A1AA28C6B15D@sri.com>
Date: Tue, 30 Jul 2013 11:52:57 +0100
Message-ID:
Subject: Re: Persona and BrowserID integration
From: Dale Harvey
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001a11c3a94c70dabb04e2b8693c
X-Gm-Message-State: ALoCoQnQEUivjN4XAaeF44wTJh5QtfveYELGJTZD2u9yZO75YedTZ3J9FtaS6kc2VaPGENj7UnZT
X-Virus-Checked: Checked by ClamAV on apache.org
--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 wrote:
>
> On Jul 29, 2013, at 18:29 , Jason Smith wrote:
>
> >
> > On Mon, Jul 29, 2013 at 11:24 PM, Dirkjan Ochtman
> wrote:
> >> On Mon, Jul 29, 2013 at 5:24 PM, Dale Harvey
> 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--