Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.132.243 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=C4LqtSVfjAQsxlZAZNUyJSuqqCcuHs1aH1MYQQnrKcZY7otgxs1H5cuxL+3sw9c5WR
         /7CtVds0MEI1yh25CI96KmhG5G5K7dl5RAJ8cUp0QNMq+ArAoZYlBiUY9P/sEMQ+W+GI
         O2VhESfRHTH7ZmMQmZczgZmXvZ838WFG3dVdE=
MIME-Version: 1.0
In-Reply-To: <46aeb24f0906201424u56b0e295we4c86851d7ebe0b0@mail.gmail.com>
References: <9DE8D039-6E7F-43C5-A9AD-BEBE6A4DCA5F@apache.org>
	 <cd7634ce0906191342x17bcbe19w14807e63679da946@mail.gmail.com>
	 <6b6419750906191356p7fc6a06bwf7643cd5ba5ca067@mail.gmail.com>
	 <46aeb24f0906201424u56b0e295we4c86851d7ebe0b0@mail.gmail.com>
Date: Sun, 21 Jun 2009 17:56:19 -0400
Message-ID: <e2111bbb0906211456i14f75498pe9d2b80275495712@mail.gmail.com>
Subject: Re: The 1.0 Thread
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Sat, Jun 20, 2009 at 5:24 PM, Robert Newson<robert.newson@gmail.com> wrote:
> If there's anything I could do to more tightly integrate
> couchdb-lucene with core to accomplish one of your bullet points, I'm
> listening. I pushed a 0.3 release last week and I'm pretty happy with
> the API, I don't see any major breaking changes coming any time soon,
> just new features as I get time.
>
> +1 million for "hash as revision". It would be very cool to be able to
> write the same change to N boxes and have that not be a conflict.
>
> B.
>
> On Fri, Jun 19, 2009 at 9:56 PM, Patrick Aljord<patcito@gmail.com> wrote:
>> +1 on ability to intersect (or union) multiple view results.
>> URL rewrite handler and Built-in authentication would be nice for couchapps.
>>
>

Also +lots on deterministic revisions. As a side note, we've been
worrying a bit about how to calculate the revision id's in the face of
JSON differences in clients. I make a motion that we just stop caring
and define how we calculate the signature. Ie, instead of calling it
canonical JSON just call it, "The CouchDB deterministic revision
algorithm" or some such. Then we can feel free to punt on any of the
awesome issues we'd run into with a full canonical JSON standard.

Paul Davis