From dev-return-18377-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Oct 4 23:45:39 2011 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 0B1007727 for ; Tue, 4 Oct 2011 23:45:39 +0000 (UTC) Received: (qmail 15905 invoked by uid 500); 4 Oct 2011 23:45:38 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 15873 invoked by uid 500); 4 Oct 2011 23:45:38 -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 15865 invoked by uid 99); 4 Oct 2011 23:45:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2011 23:45:38 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.220.180 as permitted sender) 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, 04 Oct 2011 23:45:30 +0000 Received: by vcbf11 with SMTP id f11so1397936vcb.11 for ; Tue, 04 Oct 2011 16:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=nxk1SP/2KF3mUi/S++/E8ZY7JYwaeMYOQkR9WXnYd7M=; b=dFv+B3tR6b5r1AtHJtO94nfoGV7M6b/c+vK0X0DTLGJ9FAIKAHmKm65XHYInLeQXYM g5LiPsIwPXQ+luWhXt9au5M5e8MHZhAVOBgWrIcq7rcAC9iDEzGkZIEnmBIXQy09V4V+ EpgwEeK9O9CYwVfMh2ly3bQ5i/PZNrA1RactE= Received: by 10.52.24.240 with SMTP id x16mr1834001vdf.113.1317771910112; Tue, 04 Oct 2011 16:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.134 with HTTP; Tue, 4 Oct 2011 16:44:30 -0700 (PDT) In-Reply-To: References: From: Paul Davis Date: Tue, 4 Oct 2011 18:44:30 -0500 Message-ID: Subject: Re: Universal Binary JSON in CouchDB To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Oct 4, 2011 at 4:24 PM, Benoit Chesneau wrote= : > On Tue, Oct 4, 2011 at 10:18 PM, Robert Newson wrote= : >> -1 >> >> Supporting multiple formats on disk would be a very difficult code >> change that would complicate every part of the system, I don't think >> it's worth it. >> >> > > The real problem I see is maintening different format with views and > replication, t will indeed complicate things. =A0There are also oher > tricks that can be used on http/tcp level to speed things. Like > supporting websockets or other things like that. > > > - benoit > Yeah, it gets interesting quickly. But that's why I think we should have the first step of basing things off the accept header for request/response bodies only. *If* something other than JSON turns into a noticeable improvement, then we *may* add a replication thing to use it. But promising to do so right out is, I think, overreaching a bit. Plus, if we can't manage to have accept based content-type switching, why should we think we'd be any better at supporting it internally?