From couchdb-user-return-560-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Thu Jun 19 08:19:40 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 88547 invoked from network); 19 Jun 2008 08:19:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Jun 2008 08:19:40 -0000 Received: (qmail 7142 invoked by uid 500); 19 Jun 2008 08:19:41 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 7121 invoked by uid 500); 19 Jun 2008 08:19:41 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 7110 invoked by uid 99); 19 Jun 2008 08:19:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jun 2008 01:19:41 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates 209.85.146.182 as permitted sender) Received: from [209.85.146.182] (HELO wa-out-1112.google.com) (209.85.146.182) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jun 2008 08:18:49 +0000 Received: by wa-out-1112.google.com with SMTP id m16so518867waf.6 for ; Thu, 19 Jun 2008 01:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=tLdONMgZEKAMs1cXNePoIwKjVtXLVp7c3pU71iUtp4g=; b=FRU5BW74S87oCkqmhn/t7JJcigHuhJhwhseCHCqjzZRcCKmPhDpOHYzGjguR37jste YB+7Q25BmW5d0SDEKUKDlzUvwi2GtX1lNsyOfTNtwlZXZf+E0lUAGsul2hjC06EvIjZb FzjUoJ+v8whcBAs7BLipIos3by/ow4QVgS73s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=xb9IK5XmppOfNDLX1bVnIFIIi1cqe4NOjkAAKrMwMiWb4scwURgeezDiq6bnPZiVeZ gAN5Xo1i6ngahpiG4o3LQblif1R5JdlayctPpMfgfZijHuoNDQHkP+lXFc3wCOdx8jf8 LHcxL9FykSP4NVeS/CBteRCDicQOOxIIXZV8U= Received: by 10.114.144.1 with SMTP id r1mr2044280wad.140.1213863547838; Thu, 19 Jun 2008 01:19:07 -0700 (PDT) Received: by 10.115.91.19 with HTTP; Thu, 19 Jun 2008 01:19:07 -0700 (PDT) Message-ID: Date: Thu, 19 Jun 2008 01:19:07 -0700 From: "Chris Anderson" Sender: jchris@gmail.com To: couchdb-user@incubator.apache.org Subject: Re: gathering requirements for the plugin system In-Reply-To: <485A0521.5070303@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <485A0521.5070303@gmail.com> X-Google-Sender-Auth: 0dd582b27a1d599d X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Jun 19, 2008 at 12:05 AM, Brad Schick wrote: > > 1) Provide a way for plugins to install and access standard views. > 2) Let each plugin instance provide a map (and perhaps reduce) function for > itself. > > I like #2 better because the "view" would be directly attached to the plugin > rather than being independent. In my experience invisible dependencies lead > to problems. But with either solution callers should be able to use the > standard view like query options; key, startkey, endkey, count, etc. > An argument for #1 is that in uses cases like mine (millions of docs) the presence of "extra" views can be a real headache. Users can just provide the views necessary for the plugins to function. I like #1 also because it is "generative" as they say. By that I mean people can come up for new and interesting ways to use the underlying feature (in this case the ability to query couchdb from your plugin) that we can never anticipate. > Another thought: If plugins want to maintain state that depends on couchdb > documents, won't they need a notification facility? Filtering these > notifications would be another good use of map (and perhaps reduce) > functions associated directly with plugins. > There's currently the DbUpdateNotificationProcess, which I suppose is another good candidate to be treated as a plugin. I wish I had a deeper understanding of the Erlang internals (where it would be convenient to draw the line between plugin and the code that hosts it). I guess there is some common server interface we could extract, and allow plugins to register for inclusion in. And then there are private paths, both in the document-id namespace (eg _design) and in the query-time url namespace (eg _view). Some plugins will want to be passed all the documents in the database (like views do, and the runners I describe in the wiki) and some plugins will want to operate at query time (like search). Brad makes the suggestion that some plugins may want to operate on the contents of a map or reduce view. Hopefully we can find a few more edge cases and out-there ideas so we have a full picture before we try to cut it down to just the essentials and start writing code. -- Chris Anderson http://jchris.mfdz.com