couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Universal Binary JSON in CouchDB
Date Tue, 04 Oct 2011 20:18:19 GMT

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.

If we were to contemplate just multiple http payload formats, I would
rather support one with broader acceptance (and with the caveat that
it would have to have some compelling reason beyond being just another
format). I'm aware of Tim's work on messagepack but I believe it's run
aground for the technical reasons I alluded to above.

Bottom line: I'd focus on optimizing the JSON encode/decode layer
first before considering anything as dramatic as this. Paul Davis
wrote a very fast JSON encoder/decoder called 'jiffy'. I would like to
hear more about that.


On 4 October 2011 21:08, Benoit Chesneau <> wrote:
> On Tue, Oct 4, 2011 at 9:33 PM, Paul Davis <> wrote:
>> For a first step I'd prefer to see a patch that makes the HTTP
>> responses choose a content type based on accept headers. Once we see
>> what that looks like and how/if it changes performance then *maybe* we
>> can start talking about on disk formats. Changing how we store things
>> on disk is a fairly high impact change that we'll need to consider
>> carefully.
> +1
>> 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.
> I think I would prefer to use protobuffs format though. Anyway if wwe
> change the api to handle all types that would be pluggable without
> problem.
> - benoƮt

View raw message