couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominic Tarr <>
Subject Re: status of universal binary json in couchdb
Date Wed, 12 Oct 2011 05:59:21 GMT
okay, interesting.

that sounds a bit more difficult than the parser! but nevertheless the right

I'll admit now that I do not know erlang yet. I've been wanting to get into
it though, and implementing ubj seemed both interesting and useful.
refactoring couchbd, prehaps more challenging.

good to know the lie of the land, thanks for your answer!

cheers, Dominic

On Wed, Oct 12, 2011 at 3:43 PM, Paul Davis <>wrote:

> On Tue, Oct 11, 2011 at 11:17 PM, Dominic Tarr <>
> wrote:
> > I read here
> > that
> > UBJ was under consideration?
> >
> > The spec for ubj looks quite good, but there are not many implementations
> > available yet.
> > I am considering writing some in (node)js and erlang.
> >
> > would support for ubj be added if there where supporting libraries
> > available.
> >
> > I have searched the archives and not found any discussion on this yet.
> >
> > cheers, Dominic.
> >
> Dominic,
> We've discussed the possibility (possibility mind you) of adding it.
> As you note it's quite young and hasn't reached wide spread adoption
> and its always hard to guess about the future.
> The current status is basically that it'd be interesting to see a
> patch to CouchDB that abstracts the content generation for the JSON
> responses such that alternative content types could be implemented
> along with a patch that uses that API for JSON and UBJSON. Then we'd
> need to look into the performance characteristics and end-user support
> (ie, perhaps it could be a plugin).
> I won't sugar coat it. It'll be a tough sell to get something other
> than JSON into CouchDB as an officially supported Content-Type. It'll
> take quite a bit of work marshaling the patch through the technical
> and community aspects of such a change.
> That said if you or anyone else wants to move forward with it, I would
> propose a rough outline. First, a patch that abstracts the JSON
> generation into a generic API as well as the JSON reference
> implementation of that API. Second, a robust system for choosing the
> correct content-type based on HTTP Accept headers. And third, an
> alternative implementation using UBJSON.
> I'll restate that this would be a significant amount of work and
> there's always the possibility that the end result doesn't include
> alternative content-types in trunk. (Assuming the abstract API was
> solid I don't see us not acception that patch, but I make no promises
> :)
> Other notes:
> There was a discussion here:
> Also, if you're interested in writing an Erlang version, I'd be
> interested in a patch to Jiffy [1]. I've been meaning to sit down and
> write it but its not a priority.
> [1]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message