couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: status of universal binary json in couchdb
Date Wed, 12 Oct 2011 04:43:27 GMT
On Tue, Oct 11, 2011 at 11:17 PM, Dominic Tarr <dominic.tarr@gmail.com> wrote:
> I read here https://plus.google.com/107397941677313236670/posts/LFBB233PKQ1
> 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:

http://mail-archives.apache.org/mod_mbox/couchdb-dev/201109.mbox/%3CCABn9xAGK0WbPhpkbxyKQo9N1KEsm=rx81V7FVDaRGPjXjncvWQ@mail.gmail.com%3E

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] https://github.com/davisp/jiffy

Mime
View raw message