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 >
