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.
B. On 15 April 2012 12:56, Robert Newson <rnew...@apache.org> 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. > http://en.wikipedia.org/wiki/Cross-origin_resource_sharing > > 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. > http://en.wikipedia.org/wiki/Server-sent_events > > 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] > http://en.wikipedia.org/wiki/SPDY > > 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 <dio...@dionne-associates.com> 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 <rnew...@apache.org> wrote: >>>> He's what I have so far: https://gist.github.com/2387973 >>>> >>>> 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 >>
