Ah, that's easier. If the question is "do we support a binary format for responses" I'd vote "no".
That doesn't mean we shouldn't improve the speed of what we have, though. B. On 4 October 2011 22:43, Riyad Kalla <[email protected]> wrote: > 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 <[email protected]> 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 >> >
