couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Help shape the future of CouchDB: your voice needed!
Date Sun, 15 Apr 2012 11:56:39 GMT
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 <dionne@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 <rnewson@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
>

Mime
View raw message