From dev-return-21146-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Feb 28 03:10:49 2012 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 1D44C9CE8 for ; Tue, 28 Feb 2012 03:10:49 +0000 (UTC) Received: (qmail 84505 invoked by uid 500); 28 Feb 2012 03:10:48 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 84454 invoked by uid 500); 28 Feb 2012 03:10:48 -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 84443 invoked by uid 99); 28 Feb 2012 03:10:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Feb 2012 03:10:48 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Feb 2012 03:10:37 +0000 Received: by vcbfl10 with SMTP id fl10so1998674vcb.11 for ; Mon, 27 Feb 2012 19:10:15 -0800 (PST) Received-SPF: pass (google.com: domain of jhs@iriscouch.com designates 10.52.25.107 as permitted sender) client-ip=10.52.25.107; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jhs@iriscouch.com designates 10.52.25.107 as permitted sender) smtp.mail=jhs@iriscouch.com Received: from mr.google.com ([10.52.25.107]) by 10.52.25.107 with SMTP id b11mr10024307vdg.37.1330398615378 (num_hops = 1); Mon, 27 Feb 2012 19:10:15 -0800 (PST) Received: by 10.52.25.107 with SMTP id b11mr8278601vdg.37.1330398615218; Mon, 27 Feb 2012 19:10:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.106.130 with HTTP; Mon, 27 Feb 2012 19:09:55 -0800 (PST) In-Reply-To: <4F4C1BDF.8010305@gmx.de> References: <4F4C1BDF.8010305@gmx.de> From: Jason Smith Date: Tue, 28 Feb 2012 10:09:55 +0700 Message-ID: Subject: Re: feasibility of a design doc option to use the "ddoc new"/"ddoc " based protocol for map and reduce as well To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQma3pQ8IAYb9PGcRap+O09qjwxMQ6Or3LDzPRhj5UX648ZwPaS3vpSvXiUDFW9HJOzL1pVQ X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Feb 28, 2012 at 7:12 AM, Ronny Pfannschmidt wrote: > Hi, > > while trying to build a a view server for ddocs that validate/support > documents as FSM (Finite State Machine) > i hit a inherent limit of the protocol, > > map and reduce don't get the full ddoc, but only a part of it, > which means my view server can't actually work with the full ddoc > unless i do some weird hacks, and end up in a situation, > where i circumvent proper view invalidation > > if map/reduce where allowed to opt in for using the newer protocol for > accessing functions, > my problem would go away > > as for view invalidation, a simple variant could just use the _rev, > a more sophisticated one would take a hash of parts of the document > (using excludes/includes defined in options as well) Hi, Ronny. Are you aware that the contents of .views.lib are sent to the view server? At least with Javascript, the idea is that CommonJS modules can go in there. Maybe that can help as a workaround for now. -- Iris Couch