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 52B6379A2 for ; Tue, 4 Oct 2011 21:44:45 +0000 (UTC) Received: (qmail 26107 invoked by uid 500); 4 Oct 2011 21:44:44 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 26073 invoked by uid 500); 4 Oct 2011 21:44:44 -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 26064 invoked by uid 99); 4 Oct 2011 21:44:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2011 21:44:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rkalla@gmail.com designates 209.85.213.180 as permitted sender) Received: from [209.85.213.180] (HELO mail-yx0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2011 21:44:40 +0000 Received: by yxm34 with SMTP id 34so1351856yxm.11 for ; Tue, 04 Oct 2011 14:44:19 -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; bh=bKUv38f1IUvM9HZLIAk/M265Q1ObM80gEU2frT/oajU=; b=lkLkGUjF58YRzCu5JvL6VbZRu+77P/nYsY4JyCyMEpgB4V3zr2aSLHc3Ara5ZL7PFR 3o4cPO6wGQwA9BkSM8ZIFRF/LNm3GQ2jO0QCU1tpJ1u0lqhwfddf2Kq0zzPAiKf6sLQb nkaT/yN6nzzTN/rp00C1W8962r1ZHlR8fAvlc= Received: by 10.150.240.8 with SMTP id n8mr1769656ybh.289.1317764658100; Tue, 04 Oct 2011 14:44:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.83.1 with HTTP; Tue, 4 Oct 2011 14:43:48 -0700 (PDT) In-Reply-To: References: From: Riyad Kalla Date: Tue, 4 Oct 2011 14:43:48 -0700 Message-ID: Subject: Re: Universal Binary JSON in CouchDB To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=000e0cd3530457fadc04ae7ffea7 --000e0cd3530457fadc04ae7ffea7 Content-Type: text/plain; charset=ISO-8859-1 Tim's work is certainly the catalyst for my excitement about the potential here for Couch. As Paul pointed out, the correct discussion to have at this point is really about "do we support a binary format for responses" and if so "which one"? That discussion could go on for an eternity with everyone voting for their favorite (protobuff, smile, messagepack, etc.). The only reason I bring up the "disk store format" discussion into this conversion is to offer a hat-tip to a future where a binary response format selected now may dovetail nicely with alternative binary disk formats, enabling the stream-directly-from-disk scenario. If we were to hypothetically remove the possibility of the on-disk format ever changing, then I suppose the decision of binary response format just becomes an issue of "Which one is fast and easy to generate?". -R On Tue, Oct 4, 2011 at 12:49 PM, Ladislav Thon wrote: > > > > That said, the ubjson spec is starting to look reasonable and capable > > to be an alternative content-type produced by CouchDB. If someone were > > to write a patch I'd review it quite enthusiastically. > > > Just FYI, there's an experimental support for MessagePack by Tim Anglade: > https://github.com/timanglade/couchdb/commits/msgpack I thought it might > be > interesting in this debate... Tim says it improves performance quite a bit: > http://blog.cloudant.com/optimizing-couchdb-calls-by-99-percent/ (Tim, if > you're reading this, thank's for the excellent talk!) > > LT > --000e0cd3530457fadc04ae7ffea7--