couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Help shape the future of CouchDB: your voice needed!
Date Sun, 15 Apr 2012 12:10:38 GMT
A bit busy right now but _history seems the exact opposite of the _rev
-> _mvcc name change. We want to clarify that CouchDB does *not*
provide history.


On 15 April 2012 12:56, Robert Newson <> wrote:
> Including comments from the gist;
> from mcoolin;
> I'd add a definitions section for the following:
> CORS - Cross-origin resource sharing (CORS) is a web browser
> technology specification, which defines ways for a web server to allow
> its resources to be accessed by a web page from a different domain.
> EventSource - Server-sent events is a technology for providing push
> notifications from a server to a browser client in the form of DOM
> events. The Server-Sent Events EventSource API is now being
> standardized as part of HTML5[1] by the W3C.
> SPDY - SPDY (pronounced speedy)[1] is an experimental networking
> protocol developed primarily at Google for transporting web
> content.[1] Although not currently a standard protocol, the group
> developing SPDY has stated publicly that it is working toward
> standardization (available now as an Internet Draft[2]), and has
> reference implementations available in both Google Chrome [3] and
> Mozilla Firefox.[4] SPDY is similar to HTTP, with particular goals to
> reduce web page load latency and improve web security. SPDY achieves
> reduced latency through compression, multiplexing, and
> prioritization.[1] The name is not an acronym, but is a shortened
> version of the word "speedy".[5] SPDY is a trademark of Google.[6]
> I would include the two lists in any upcoming vote, perhaps as separate votes.
> A few other comments:
> On Number 4 in the first list: Seems to be only a partial description,
> remove data from record and do what with it? How would it be accessed
> and used. especially _id, likely to have a major impact on any project
> using couchdb.
> On number 3: Hard dependencies on SpiderMonkey, Should this not be
> discussed more? Performance being a big issue, V8 may be a better
> choice or a set of native erlang routines or some other derivative.
> and my reply;
> I deliberately left out definitions for those on the basis that if you
> don't know what they are, you have no business asserting its a high
> priority for our project.
> For item 4, the description does state that a question remains on
> where they go and suggests custom HTTP headers, so I don't follow your
> point. _id in particular would still be in the URL.
> For the spidermonkey issue, it is not at all clear that switching to
> V8 will improve performance (it's largely a myth that V8 is faster
> than spidermonkey anyway). The main feature for improving performance
> is identified as "View server protocol enhancements/refactoring".
> On 15 April 2012 12:25, Bob Dionne <> wrote:
>> Benoit,
>> Thanks for mentioning the "links" item, that should definitely be in the list. I'd
be curious to know what kind if usage the Basho folks have seen with that one.
>> I think it's a good feature but I also think it kind of runs against the grain architecturally
in couchdb. Documents now are completely independent of one another which is simple. This
forces use cases that need "links" to do so in the application layer. There are many reasons
I think of that folks would want this, building trees, graphs, SQL-like queries, navigation,
etc. so I think it's a nice feature to add, *but* I would do so in a way that doesn't change
the independence of documents, .ie. make it orthogonal, a plugin to core.
>> Bob
>> On Apr 15, 2012, at 6:17 AM, Benoit Chesneau wrote:
>>> On Sun, Apr 15, 2012 at 12:02 PM, Robert Newson <> wrote:
>>>> He's what I have so far:
>>>> I think it's pretty close. Only the User-Facing section should be in
>>>> the next vote.
>>>> B.
>>> Most is OK for me. A couple of remarks on user facing though:
>>> 1.3 : _rev renaming should be placed in another part, and maybe a
>>> developper facing thing . Also other way to embrace it is proposing an
>>> _history member.
>>> 3. we shouldn't talk about a specific tech. As far as I rememebr we
>>> only talk on a distributed PKI wich openid isn't. OpenID is fine but
>>> maybe we can put the choice of supported implementations for a next
>>> vote?
>>> 4. maybe can be summarized as "metadata won't be exposed in the Json
>>> Document" ? Or at least the raw document won't be edited by couch.
>>> Some on irc for example was proposing for example to have {"_id": ...,
>>> "_raw": ...}
>>> links/nested doc feature is missing .
>>> I will do another round on dev facing features later.
>>> - benoƮt

View raw message