Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <41C0C348-0328-477C-A389-107155A2A62B@dionne-associates.com>
References: <20120414002434.GA22219@atypical.net>
	<1334416226.2951.1.camel@devil>
	<91DAAC41-2AE8-44F0-88A4-FFFDC927E277@dionne-associates.com>
	<CABvT1DGksHPbr2YDiBUksZEUkcHSJBbfBSdGoh4hrisTN7gJWQ@mail.gmail.com>
	<CAJNb-9p_xEf6dpoHu09MxaOJzn6i5mnwxC9kZEy2cERHaqOaoQ@mail.gmail.com>
	<CABvT1DF+b=7a_QVboVcGjJ2BRfLKzv-GrFzLFQqMGQmLd_ZMWw@mail.gmail.com>
	<CAJNb-9p4dH_owTQnXPGuspae6fh0sGb14Ge6mwOeZ2bE6YVP1g@mail.gmail.com>
	<41C0C348-0328-477C-A389-107155A2A62B@dionne-associates.com>
Date: Sun, 15 Apr 2012 12:56:39 +0100
Message-ID: 
 <CABvT1DGs+B4CJMuLiiaNajK9NNDvW51jMJE5812i13pp3F-rvA@mail.gmail.com>
Subject: Re: Help shape the future of CouchDB: your voice needed!
From: Robert Newson <rnewson@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 vot=
es.

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 w=
ith 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 folk=
s would want this, building trees, graphs, SQL-like queries, navigation, et=
c. 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 p=
lugin 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> wro=
te:
>>> 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=EEt
>