From couchdb-dev-return-1384-apmail-incubator-couchdb-dev-archive=incubator.apache.org@incubator.apache.org Thu Dec 04 18:06:09 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-dev-archive@locus.apache.org Received: (qmail 90055 invoked from network); 4 Dec 2008 18:06:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Dec 2008 18:06:09 -0000 Received: (qmail 38780 invoked by uid 500); 4 Dec 2008 18:06:21 -0000 Delivered-To: apmail-incubator-couchdb-dev-archive@incubator.apache.org Received: (qmail 38508 invoked by uid 500); 4 Dec 2008 18:06:20 -0000 Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-dev@incubator.apache.org Delivered-To: mailing list couchdb-dev@incubator.apache.org Received: (qmail 38497 invoked by uid 99); 4 Dec 2008 18:06:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Dec 2008 10:06:20 -0800 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.221.10 as permitted sender) Received: from [209.85.221.10] (HELO mail-qy0-f10.google.com) (209.85.221.10) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Dec 2008 18:04:49 +0000 Received: by qyk3 with SMTP id 3so3641382qyk.12 for ; Thu, 04 Dec 2008 10:04:34 -0800 (PST) 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=RjaA6YJuw5yufEX6agcW3i785yfbPn2/hS9tbgwrrpU=; b=CRSLNOLFyT37l5F4xQwzYg/97xp023WmrZm82klV5Hb6bvfiiAgZE+9JqlBMS79jMP yvtWAPUlS8M/rjjV0wy7Qn4wag0Pd11LLo+Yq3KDn2BCkwOt3Rs4V94dmDsn/9wD5+RS mbAq7mkHHJlF2xoYi1C3bjoNvd4TxYLvJ8hkA= 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=dMWQGEQq/Gqht98KIMh1FBaTBm1voy35J4q0B0oCIydveyAQmjKuI8LPj3Fmn5f4pV b3GVA1Q2kixHHS/2STXyW0dApARBvMHml0edVKicvXzBV2DXDzVwDOYTeLBL9zqQZNEv 0GSRlAGt7yJLmf3b2r/1qrHYA/IIhsakf/uKs= Received: by 10.65.197.16 with SMTP id z16mr14453339qbp.25.1228413873428; Thu, 04 Dec 2008 10:04:33 -0800 (PST) Received: by 10.65.235.11 with HTTP; Thu, 4 Dec 2008 10:04:33 -0800 (PST) Message-ID: Date: Thu, 4 Dec 2008 10:04:33 -0800 From: "Chris Anderson" Sender: jchris@gmail.com To: couchdb-dev@incubator.apache.org Subject: Re: API suggestions In-Reply-To: <214c385b0812040401r4f90146bw17a8526018fe4c98@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <214c385b0812040401r4f90146bw17a8526018fe4c98@mail.gmail.com> X-Google-Sender-Auth: afeba9f3f729c3f7 X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Dec 4, 2008 at 4:01 AM, Matt Goodall wrote: > I'm aware that some are significant changes and would break language > bindings but better now than post 1.0! I'll try to answer without regard for breaking changes that would be the result. > > = Document Revisions = > > Identify document revision using a segment arg instead of query param, e.g. > I think the current ?rev=revstring approach is nice because in the normal case, you'll be requesting the attachment without a rev specified (eg you just want the latest). Standard query params are also a little easier to deal with both in client libraries and in Mochiweb. > > = Document Bits = > > > = Reserved Names = > > Following on from "Document Bits", would it be sensible to reserve > *all* path segments beginning with an underscore for CouchDB's use? > This is worth at least thinking about. Having the _attachments path would open the door to an attachments index view, as well as attachments with literal '/' in the name. What do people think of the _attachment path as a way out of the %2F dilemma? > > = View API - start/end pairs = > > Would it make sense to combine the startXXX and endXXX pairs into a > single range query param. Doesn't make sense. 90% of the time I specify a startkey without an endkey or vice versa. > > = View API - map/reduce/rereduce control = > "map" => reduce=false > "reduce" => reduce=true&group=true > "rereduce" => reduce=true&group=false > It's a little more complex than that, and built with future extensibility in mind. For instance, you can have more than one named reduce per map function, eventually, by using built-in erlang views. eg: reduce=sum or reduce=row_count. -- Chris Anderson http://jchris.mfdz.com