You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2009/01/23 23:42:13 UTC
VOTE: accept newline patch into CouchDB for 0.9
Hey,
I've been simultaneously looking forward to and dreading this, but here goes.
We need to decide a resolution for COUCHDB-107:
End JSON responses with newline char
This ticket has a patch, and it's been discussed to death on the mailing list.
The summary of the arguments are:
* PRO: It is POSIXly correct and improves usability from the command line
* CON: It might not conform to a future canonical JSON representation
Even though this seems to be the colour of our very own bikeshed, we still need
to paint the damn thing, so I think it's best to decide the colour once and for
all and get on with releasing 0.9 along with any other API changes.
Along those lines, I hereby present four options and an informal vote:
* Accept the patch (or a modified version) and add newline chars
* Reject the patch (and any modified version) and do not add newlines chars
* Further discussion, to be decided before we release 0.9
* Further discussion, to be decided after we release 0.9
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jan 23, 2009 at 06:15:09PM -0500, Dean Landolt wrote:
> Sorry, completely dense -- I thought I had Antony's quoted (my votes
> entirely)
Aha, thanks!
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Dean Landolt <de...@deanlandolt.com>.
On Fri, Jan 23, 2009 at 5:57 PM, Noah Slater <ns...@apache.org> wrote:
> On Fri, Jan 23, 2009 at 05:53:56PM -0500, Dean Landolt wrote:
> > This is the standard pattern, right? In any event, +1
>
> Hehe. Again, what are you voting on? There were four options.
>
> Your plus one vote doesn't seem to be attached to any of the options.
>
> If you want, a vote on all four separately would be great!
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Sorry, completely dense -- I thought I had Antony's quoted (my votes
entirely)
* Accept the patch (or a modified version) and add newline chars
+1
* Reject the patch (and any modified version) and do not add newlines chars
-1
* Further discussion, to be decided before we release 0.9
+0
* Further discussion, to be decided after we release 0.9
-0
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jan 23, 2009 at 05:53:56PM -0500, Dean Landolt wrote:
> This is the standard pattern, right? In any event, +1
Hehe. Again, what are you voting on? There were four options.
Your plus one vote doesn't seem to be attached to any of the options.
If you want, a vote on all four separately would be great!
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Dean Landolt <de...@deanlandolt.com>.
On Fri, Jan 23, 2009 at 5:51 PM, Antony Blakey <an...@gmail.com>wrote:
>
> On 24/01/2009, at 9:12 AM, Noah Slater wrote:
>
> * Accept the patch (or a modified version) and add newline chars
>>
>
> +1
>
> A newline provides a simple way to determine end-of-term without otherwise
> parsing the json.
>
> * Reject the patch (and any modified version) and do not add newlines
>> chars
>>
>
> -1
>
> The newline isn't part of the JSON response, but is instead a transport
> issue, and so I don't think it intersects with any canonical representation
> issues.
>
> * Further discussion, to be decided before we release 0.9
>>
>
> +0
>
> * Further discussion, to be decided after we release 0.9
>>
>
> -0
>
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> The difference between ordinary and extraordinary is that little extra.
>
>
>
This is the standard pattern, right? In any event, +1
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Antony Blakey <an...@gmail.com>.
On 24/01/2009, at 9:12 AM, Noah Slater wrote:
> * Accept the patch (or a modified version) and add newline chars
+1
A newline provides a simple way to determine end-of-term without
otherwise parsing the json.
> * Reject the patch (and any modified version) and do not add
> newlines chars
-1
The newline isn't part of the JSON response, but is instead a
transport issue, and so I don't think it intersects with any canonical
representation issues.
> * Further discussion, to be decided before we release 0.9
+0
> * Further discussion, to be decided after we release 0.9
-0
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The difference between ordinary and extraordinary is that little extra.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Brian Candler <B....@pobox.com>.
On Mon, Feb 23, 2009 at 07:48:46PM +0000, Noah Slater wrote:
> On Mon, Feb 23, 2009 at 10:48:22AM +0100, Jan Lehnardt wrote:
> > I haven't seen any compelling pro- arguments that can't be solved
> > on the client side (curl -w\\n e.g.).
>
> Having to solve on the client side IS the problem. :)
Indeed. And the current situation is anomalous: if there are objections to a
trailing newline, surely newlines should be removed from within view results
too. (I don't want this though; I want them to be kept and the trailing one
added).
Incidentally, I looked at the code and the internal newlines are \r\n - so
the trailing one should be this too, IMO.
send_json_view_row(Resp, Db, {{Key, DocId}, Value}, RowFront, IncludeDocs) ->
JsonObj = view_row_obj(Db, {{Key, DocId}, Value}, IncludeDocs),
RowFront2 = case RowFront of
nil -> ",\r\n";
_ -> RowFront
end,
send_chunk(Resp, RowFront2 ++ ?JSON_ENCODE(JsonObj)).
Regards,
Brian.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Mon, Feb 23, 2009 at 10:48:22AM +0100, Jan Lehnardt wrote:
> I haven't seen any compelling pro- arguments that can't be solved
> on the client side (curl -w\\n e.g.).
Having to solve on the client side IS the problem. :)
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Christopher,
On 23 Feb 2009, at 10:31, Christopher Lenz wrote:
> Personally, I don't think this whole thing is very important, but I
> don't see any harm in adding the trailing newline right now.
Me neither. The only thing is that it changes the API and we agreed to
solve these issues within the next one or two releases. If we decide
that
we can change this particular behaviour of the API later without
breaking
clients, we can drop the 'blocking' bit and move on.
> Providing a reason for your -1 on accepting the patch would be a
> good start ;)
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200901.mbox/%3ce282921e0901261309y51bc9519v6583f2b0a9d7ed84@mail.gmail.com%3e
I haven't seen any compelling pro- arguments that can't be solved
on the client side (curl -w\\n e.g.).
Cheers
Jan
--
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
On 24 Feb 2009, at 04:08, Chris Anderson wrote:
> On Mon, Feb 23, 2009 at 1:31 AM, Christopher Lenz <cm...@gmx.de>
> wrote:
>
>>
>> Providing a reason for your -1 on accepting the patch would be a
>> good start
>> ;)
>>
>> Personally, I don't think this whole thing is very important, but I
>> don't
>> see any harm in adding the trailing newline right now.
>>
>
> I'm basically of the same mind. It's not very important to me either
> way. I don't use command line clients much (oh and my bash-prompt has
> a newline in it anyway...) so I lean slightly toward the "be like
> Google and others" side of the fence.
>
> If I understand correctly, Damien's objections have to do with the
> interaction between a trailing newline and a potential future
> canonical JSON format. He may have a point but we'd likely have to
> change other things in the future if we wanted to use that canonical
> format anyway. (Or maybe I'm mischaracterizing his old argument...)
Quick straw-poll whether this should be removed from the 0.9 (0.10)
blocking list?
+1
Cheers
Jan
--
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Feb 23, 2009 at 1:31 AM, Christopher Lenz <cm...@gmx.de> wrote:
>
> Providing a reason for your -1 on accepting the patch would be a good start
> ;)
>
> Personally, I don't think this whole thing is very important, but I don't
> see any harm in adding the trailing newline right now.
>
I'm basically of the same mind. It's not very important to me either
way. I don't use command line clients much (oh and my bash-prompt has
a newline in it anyway...) so I lean slightly toward the "be like
Google and others" side of the fence.
If I understand correctly, Damien's objections have to do with the
interaction between a trailing newline and a potential future
canonical JSON format. He may have a point but we'd likely have to
change other things in the future if we wanted to use that canonical
format anyway. (Or maybe I'm mischaracterizing his old argument...)
--
Chris Anderson
http://jchris.mfdz.com
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Christopher Lenz <cm...@gmx.de>.
On 23.02.2009, at 10:20, Jan Lehnardt wrote:
> On 22 Feb 2009, at 23:30, Noah Slater wrote:
>
>> On Sun, Feb 22, 2009 at 05:47:00PM +0100, Jan Lehnardt wrote:
>>> It looks like we have a draw with weigh-in from the community
>>> on a +1 to accept the patch.
>>>
>>> We need more discussion here.
>>
>> Oh wow, I was very confused by this.
>>
>> I actually announced the results on the 2009-02-01, and wondered
>> why you were
>> ignoring these... but a careful check of my mail archives reveals I
>> managed to
>> have an entire subthread replying to my own emails. What a looser.
>
> Now I'm confused, you wrote, but didn't send the RESULT mail? :)
>
> In any case, this needs discussion.
Providing a reason for your -1 on accepting the patch would be a good
start ;)
Personally, I don't think this whole thing is very important, but I
don't see any harm in adding the trailing newline right now.
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
On 23 Feb 2009, at 20:48, Noah Slater wrote:
> On Mon, Feb 23, 2009 at 10:20:12AM +0100, Jan Lehnardt wrote:
>> Now I'm confused, you wrote, but didn't send the RESULT mail? :)
>
> I had replied, but managed to reply to myself instead of the list.
I have _so_ been there before :)
Cheers
Jan
--
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Mon, Feb 23, 2009 at 10:20:12AM +0100, Jan Lehnardt wrote:
> Now I'm confused, you wrote, but didn't send the RESULT mail? :)
I had replied, but managed to reply to myself instead of the list.
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
On 22 Feb 2009, at 23:30, Noah Slater wrote:
> On Sun, Feb 22, 2009 at 05:47:00PM +0100, Jan Lehnardt wrote:
>> It looks like we have a draw with weigh-in from the community
>> on a +1 to accept the patch.
>>
>> We need more discussion here.
>
> Oh wow, I was very confused by this.
>
> I actually announced the results on the 2009-02-01, and wondered why
> you were
> ignoring these... but a careful check of my mail archives reveals I
> managed to
> have an entire subthread replying to my own emails. What a looser.
Now I'm confused, you wrote, but didn't send the RESULT mail? :)
In any case, this needs discussion.
Cheers
Jan
--
> Bellow is what I had originally written:
>
> --------------------------------------------------------------------------------
>
> The results are in, and my conclusions are:
>
> * The community and PMC have decided to open this issue back up for
> discussion, with the proviso that we complete our final decision
> before
> releasing 0.9 -- which means another vote in a week or so. Heh.
>
> * The community was strongly in favour of accepting the patch, but
> the PMC was
> almost completely split down the middle, with a slightly
> preference for not
> accepting the patch.
>
> Over the course of the vote, we had a little discussion, but maybe
> not enough.
>
> Is there anything else any wants to add? Nows the time!
>
> I know this is an annoying issue, and you wouldn't believe how
> tremendously
> boring compiling this vote result has been (learnt some new stuff
> about how to
> tot-up vote results though) -- but we need to resolve it at some
> point. Our
> ability to handle our very first bikeshed colour might be seen as an
> opportunity to demonstrate the awesome power of the CouchDB
> community. Heh heh.
>
> Go CouchDB!
>
>> * Accept the patch (or a modified version) and add newline chars
>
> Community: 7, PMC: 1
>
> +1 Noah Slater (Binding)
> +1 Antony Blakey
> +1 Dean Landolt
> +1 Paul Davis
> +1 Christopher Lenz (Binding)
> +0 Damien Katz (Binding)
> -1 Chris Anderson (binding)
> -1 Jan Lehnardt (binding)
>
>> * Reject the patch (and any modified version) and do not add
>> newlines chars
>
> Community: -4, PMC: 2
>
> -1 Noah Slater (Binding)
> -1 Antony Blakey
> -1 Dean Landolt
> -1 Paul Davis
> -0 Christopher Lenz (Binding)
> +0 Damien Katz (Binding)
> +1 Chris Anderson (binding)
> +1 Jan Lehnardt (binding)
>
>> * Further discussion, to be decided before we release 0.9
>
> Community: 5, PMC: 5
>
> +0 Noah Slater (Binding)
> +0 Antony Blakey
> +0 Dean Landolt
> -1 Paul Davis
> +0 Christopher Lenz (Binding)
> +1 Damien Katz (Binding)
> +0 Chris Anderson (binding)
>
> (Jan Lehnardt voted "0" which I am discounting)
>
>> * Further discussion, to be decided after we release 0.9
>
> Community: -3, PMC: -3
>
> -0 Noah Slater (Binding)
> +0 Antony Blakey
> +0 Dean Landolt
> -1 Paul Davis
> +0 Christopher Lenz (Binding)
> -0 Chris Anderson (binding)
> -1 Jan Lehnardt (binding)
>
> (Damien Katz didn't vote on this option)
>
> Forgot to mention my super-duper vote toting-up scheme.
>
> +1 = +2
> +0 = +1
> -0 = -1
> -1 = -2
>
> I added up these scores in total for each voting option.
>
> --------------------------------------------------------------------------------
>
>> I created "couchcurl", a stupid-simple wrapper around curl that adds
>> a newline:
>>
>> http://github.com/janl/couchcurl/tree/master
>>
>> I wanted this tool for a long time and as you can see in the TODO
>> section, this is indeed quite useful if you can specify default
>> server
>> names and port numbers so you could run
>
> I appreciate your input, and your contributions to this, but that we
> have had to
> make a WRAPPER for such a popular tool, just to improve user
> friendliness,
> should in and of itself, be an indication that something is wrong.
>
>> I understand that this does not counter all objections in the +1
>> camp,
>> but maybe we can get more support on the -1 camp through the
>> community :)
>
> Actually, going by my counting:
>
> * The community strongly wants to accept the patch
>
> * The PMC was split and strongly wants to discuss it further
>
> ... which is an odd outcome, to say the least!
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Sun, Feb 22, 2009 at 05:47:00PM +0100, Jan Lehnardt wrote:
> It looks like we have a draw with weigh-in from the community
> on a +1 to accept the patch.
>
> We need more discussion here.
Oh wow, I was very confused by this.
I actually announced the results on the 2009-02-01, and wondered why you were
ignoring these... but a careful check of my mail archives reveals I managed to
have an entire subthread replying to my own emails. What a looser.
Bellow is what I had originally written:
--------------------------------------------------------------------------------
The results are in, and my conclusions are:
* The community and PMC have decided to open this issue back up for
discussion, with the proviso that we complete our final decision before
releasing 0.9 -- which means another vote in a week or so. Heh.
* The community was strongly in favour of accepting the patch, but the PMC was
almost completely split down the middle, with a slightly preference for not
accepting the patch.
Over the course of the vote, we had a little discussion, but maybe not enough.
Is there anything else any wants to add? Nows the time!
I know this is an annoying issue, and you wouldn't believe how tremendously
boring compiling this vote result has been (learnt some new stuff about how to
tot-up vote results though) -- but we need to resolve it at some point. Our
ability to handle our very first bikeshed colour might be seen as an
opportunity to demonstrate the awesome power of the CouchDB community. Heh heh.
Go CouchDB!
> * Accept the patch (or a modified version) and add newline chars
Community: 7, PMC: 1
+1 Noah Slater (Binding)
+1 Antony Blakey
+1 Dean Landolt
+1 Paul Davis
+1 Christopher Lenz (Binding)
+0 Damien Katz (Binding)
-1 Chris Anderson (binding)
-1 Jan Lehnardt (binding)
> * Reject the patch (and any modified version) and do not add newlines chars
Community: -4, PMC: 2
-1 Noah Slater (Binding)
-1 Antony Blakey
-1 Dean Landolt
-1 Paul Davis
-0 Christopher Lenz (Binding)
+0 Damien Katz (Binding)
+1 Chris Anderson (binding)
+1 Jan Lehnardt (binding)
> * Further discussion, to be decided before we release 0.9
Community: 5, PMC: 5
+0 Noah Slater (Binding)
+0 Antony Blakey
+0 Dean Landolt
-1 Paul Davis
+0 Christopher Lenz (Binding)
+1 Damien Katz (Binding)
+0 Chris Anderson (binding)
(Jan Lehnardt voted "0" which I am discounting)
> * Further discussion, to be decided after we release 0.9
Community: -3, PMC: -3
-0 Noah Slater (Binding)
+0 Antony Blakey
+0 Dean Landolt
-1 Paul Davis
+0 Christopher Lenz (Binding)
-0 Chris Anderson (binding)
-1 Jan Lehnardt (binding)
(Damien Katz didn't vote on this option)
Forgot to mention my super-duper vote toting-up scheme.
+1 = +2
+0 = +1
-0 = -1
-1 = -2
I added up these scores in total for each voting option.
--------------------------------------------------------------------------------
> I created "couchcurl", a stupid-simple wrapper around curl that adds
> a newline:
>
> http://github.com/janl/couchcurl/tree/master
>
> I wanted this tool for a long time and as you can see in the TODO
> section, this is indeed quite useful if you can specify default server
> names and port numbers so you could run
I appreciate your input, and your contributions to this, but that we have had to
make a WRAPPER for such a popular tool, just to improve user friendliness,
should in and of itself, be an indication that something is wrong.
> I understand that this does not counter all objections in the +1 camp,
> but maybe we can get more support on the -1 camp through the
> community :)
Actually, going by my counting:
* The community strongly wants to accept the patch
* The PMC was split and strongly wants to discuss it further
... which is an odd outcome, to say the least!
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Antony Blakey <an...@gmail.com>.
On 25/02/2009, at 12:45 AM, Noah Slater wrote:
> On Wed, Feb 25, 2009 at 12:29:08AM +1030, Antony Blakey wrote:
>> My suggestion arising from this is that voting a community vote where
>> everyone states their case and casts a vote is followed by a PMC
>> decision. It seems (to me) confusing to have this multi-class voting
>> system which conflates two separate processes.
>>
>> The PMC decision would only need explanation if it were a veto of a
>> community vote.
>
> No, this jars strongly with my understanding of the Apache Way.
>
> Who is permitted to vote is, to some extent, a community-specific
> thing.
> However, the basic rule is that only PMC members have binding
> votes, and all
> others are either discouraged from voting (to keep the noise down)
> or else
> have their votes considered of an indicative or advisory nature only.
>
> -- http://www.apache.org/foundation/voting.html
>
> I think we have followed this official document to the letter, and
> in spirit.
>
> You are suggesting that Apache voting should be done by the
> community at large,
> and then the PMC should decide in private which option to take. This
> is not how
> things are meant to work. We had one vote which was opened up to
> everyone. We
> have properly taken advice from the community, but would like to
> have further
> discussion before we accept or reject the change.
OK, that's clear.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
In anything at all, perfection is finally attained not when there is
no longer anything to add, but when there is no longer anything to
take away.
-- Antoine de Saint-Exupery
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Wed, Feb 25, 2009 at 12:29:08AM +1030, Antony Blakey wrote:
> My suggestion arising from this is that voting a community vote where
> everyone states their case and casts a vote is followed by a PMC
> decision. It seems (to me) confusing to have this multi-class voting
> system which conflates two separate processes.
>
> The PMC decision would only need explanation if it were a veto of a
> community vote.
No, this jars strongly with my understanding of the Apache Way.
Who is permitted to vote is, to some extent, a community-specific thing.
However, the basic rule is that only PMC members have binding votes, and all
others are either discouraged from voting (to keep the noise down) or else
have their votes considered of an indicative or advisory nature only.
-- http://www.apache.org/foundation/voting.html
I think we have followed this official document to the letter, and in spirit.
You are suggesting that Apache voting should be done by the community at large,
and then the PMC should decide in private which option to take. This is not how
things are meant to work. We had one vote which was opened up to everyone. We
have properly taken advice from the community, but would like to have further
discussion before we accept or reject the change.
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Antony Blakey <an...@gmail.com>.
On 24/02/2009, at 10:35 PM, Jan Lehnardt wrote:
> No, you're absolutely right on the "Accept the patch" branch. But
> there are enough community -1s to keep this open. A single
> community -1 should be addressed in an ASF vote.
My suggestion arising from this is that voting a community vote where
everyone states their case and casts a vote is followed by a PMC
decision. It seems (to me) confusing to have this multi-class voting
system which conflates two separate processes.
The PMC decision would only need explanation if it were a veto of a
community vote.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
A Man may make a Remark –
In itself – a quiet thing
That may furnish the Fuse unto a Spark
In dormant nature – lain –
Let us divide – with skill –
Let us discourse – with care –
Powder exists in Charcoal –
Before it exists in Fire –
-– Emily Dickinson 913 (1865)
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
On 24 Feb 2009, at 12:44, Antony Blakey wrote:
>
> On 23/02/2009, at 3:17 AM, Jan Lehnardt wrote:
>
>> Collecting:
>>
>> On 23 Jan 2009, at 23:42, Noah Slater wrote:
>>> * Accept the patch (or a modified version) and add newline chars
>>
>> +1: 7 (2 binding)
>> -1: 3 (2 binding)
>>
>>> * Reject the patch (and any modified version) and do not add
>>> newlines chars
>>
>> +1: 3 (2 binding)
>> -1: 4
>>
>>
>>> * Further discussion, to be decided before we release 0.9
>>
>> +1: 1 (1 binding)
>> -1: 1 (1 binding)
>>
>>> * Further discussion, to be decided after we release 0.9
>>
>> +1:
>> -1: 2 (2 binding)
>>
>> --
>>
>> It looks like we have a draw with weigh-in from the community
>> on a +1 to accept the patch.
>>
>> We need more discussion here.
>
> I'm a bit confused about this. Excuse me while I tread carefully. It
> seems that the community vote is clearly a majority to accept the
> patch. If the end result of this vote is that we don't follow that
> vote because it's only the PMC vote that counts, doesn't that mean
> that community votes are irrelevant?
No, you're absolutely right on the "Accept the patch" branch. But
there are enough community -1s to keep this open. A single
community -1 should be addressed in an ASF vote.
Cheers
Jan
--
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Antony Blakey <an...@gmail.com>.
On 25/02/2009, at 1:40 AM, Jan Lehnardt wrote:
>> Instead of asking how community votes would be factored into the
>> final result,
>> you constructed a hypothetical that frames the PMC as a
>> dictatorship, doing as
>> it pleases regardless of community feedback. You then use this
>> hypothetical to
>> draw the absurd conclusion that "community votes are irrelevant"
>> and then seek
>> an explicit refutation.
My framing of this question matches the framing used in the Apache Way
excerpt that Noah included; to whit:
> However, the basic rule is that only PMC members have binding votes,
> and all others are either discouraged from voting (to keep the noise
> down) or else have their votes considered of an indicative or
> advisory nature only.
This was not an attack on the PMC, and it was not what I was thinking
when asking that question. It seemed to me that on the surface of it,
the process didn't match some underlying reality, and this except
shows that to be true. According to the Apache Way, community votes
aren't relevant to the outcome, in exactly the sense I meant. And
considering the purpose of voting, that's a good thing. Apache
discourages non-PMC members from voting.
I don't see this, or any other issue, as the PMC vs. anyone. This
project is covered in Apache goodness now.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Don't anthropomorphize computers. They hate that.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Tue, Feb 24, 2009 at 06:39:32PM +0100, Jan Lehnardt wrote:
> or just commit the damn patch :)
Committed as r747465. Rock on.
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
On 24 Feb 2009, at 18:34, Noah Slater wrote:
> On Tue, Feb 24, 2009 at 09:30:40AM -0800, Chris Anderson wrote:
>> OK actually - I have a new opinion about the newlines stuff. Since I
>> really don't care all that much, and I don't see a canonical JSON
>> format happening anytime soon, I'm fine with returning newlines at
>> the
>> end of our responses.
>
> So, that sounds like a withdrawal of your veto.
>
> ... if Jan is happy to withdraw his as well, I can call another vote.
or just commit the damn patch :)
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Tue, Feb 24, 2009 at 09:30:40AM -0800, Chris Anderson wrote:
> OK actually - I have a new opinion about the newlines stuff. Since I
> really don't care all that much, and I don't see a canonical JSON
> format happening anytime soon, I'm fine with returning newlines at the
> end of our responses.
So, that sounds like a withdrawal of your veto.
... if Jan is happy to withdraw his as well, I can call another vote.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Feb 24, 2009 at 4:31 PM, Dave Bordoley <bo...@gmail.com> wrote:
>> The real kicker is how do we support clients lacking HTTP-fu. For
>> instance, a quick google [1] suggests that XHR probably isn't capable
>> of dealing with multipart messages. There's an obvious middle ground
>> that could allow different versions to be returned via URL parameters
>> though, and then maybe provide the "all content as multipart mime" as
>> an option.
>
> You can generate multipart requests using XHR by manually coding
> together a multipart body and setting the content type header to
> multipart/form-data (why you would ever do this is beyond me, but for
> sake of argument). What you can't do is read a file from disk and
> submit it using XHR due to browser security restrictions, which is why
> ajax apps use hidden iframes to asynchronously upload files.
>
> Dave
>
Dave,
Yeah, but this is concerned with parsing a returned multipart request.
HTH,
Paul Davis
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Tue, Feb 24, 2009 at 10:25:40AM -0800, Chris Anderson wrote:
> What I mean is that there's nothing wrong with calculating revs-hashes
> in a Couch specific way. Bonus points if that way is easy to implement
> for client libs.
Aye, in the docs you simply put:
Hashes are to be calculated [with|without] the trailing newline character.
Or something to that effect.
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Chris Anderson <jc...@apache.org>.
On Tue, Feb 24, 2009 at 10:24 AM, Chris Anderson <jc...@apache.org> wrote:
> I think we have the freedom to get funny with the
> JSON responses.
Please pretend I was articulate and correct with this sentence. Thanks. ;)
What I mean is that there's nothing wrong with calculating revs-hashes
in a Couch specific way. Bonus points if that way is easy to implement
for client libs.
--
Chris Anderson
http://jchris.mfdz.com
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Damien Katz <da...@apache.org>.
That's Ok Noah. Right now, all I've got are some vague ideas, no code.
I've stated my case, unless someone else has stronger objections (or
actual code) I'm fine to leave it as is.
-Damien
On Feb 24, 2009, at 1:19 PM, Noah Slater wrote:
> On Tue, Feb 24, 2009 at 01:13:31PM -0500, Damien Katz wrote:
>> I'll once again state my objection to the newlines, which is actually
>> kind of weak.
>
> Sorry for jumping the gun there Damien.
>
> If you would like to retroactively veto the change, I can back it out.
>
> --
> Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Tue, Feb 24, 2009 at 01:13:31PM -0500, Damien Katz wrote:
> I'll once again state my objection to the newlines, which is actually
> kind of weak.
Sorry for jumping the gun there Damien.
If you would like to retroactively veto the change, I can back it out.
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Chris Anderson <jc...@apache.org>.
On Tue, Feb 24, 2009 at 10:13 AM, Damien Katz <da...@apache.org> wrote:
> I'll once again state my objection to the newlines, which is actually kind
> of weak.
>
> If we compute the revids deterministically (hash the canonical doc
> contents), then when we return the document back to the client, we can send
> as an integrity hash the same revid, because it is already pre-computed and
> stored, etc. What it could save us is the CPU cycles of computing the hash.
> I think we also get some nice free caching benefits too, but I'm not sure.
> But if we do, it might even save us the disk reads to get the doc to compute
> the hash. The problem is any standardized canonical representation is
> unlikely to included a newline at the end.
>
> Now I'm not even sure this scheme is workable either way, or only workable
> in very special instances which are too rare to be worth it. But if the
> scheme works, then it can simplify the code and make things more efficient,
> which are 2 very good things. However these benefits may never come, and
> we'll not have the newlines anyway. That would suck.
>
> But the problem if we just add the newlines, then later remove them,
> production apps and scripts that rely on that will break and make the change
> is very painful. Or impossible.
>
I don't see why we couldn't include the newlines in the input to the
hash function... For something as intimately related to CouchDB as the
calculation of revs, I think we have the freedom to get funny with the
JSON responses.
I think your point about getting the metadata out of the document
could also be accomplished by defining our function from a JSON object
to a hashable string, as one that ignores the value of _rev...
Having a special CouchDB hashable-doc function is not the prettiest
thing in the world, but we already have a bunch of other CouchDB -
only API stuff (like rereduce, etc) so I don't think it crosses an
important line.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Dave Bordoley <bo...@gmail.com>.
> The real kicker is how do we support clients lacking HTTP-fu. For
> instance, a quick google [1] suggests that XHR probably isn't capable
> of dealing with multipart messages. There's an obvious middle ground
> that could allow different versions to be returned via URL parameters
> though, and then maybe provide the "all content as multipart mime" as
> an option.
You can generate multipart requests using XHR by manually coding
together a multipart body and setting the content type header to
multipart/form-data (why you would ever do this is beyond me, but for
sake of argument). What you can't do is read a file from disk and
submit it using XHR due to browser security restrictions, which is why
ajax apps use hidden iframes to asynchronously upload files.
Dave
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Brian Candler <B....@pobox.com>.
On Fri, Feb 27, 2009 at 07:44:36AM +0000, Brian Candler wrote:
> The canonical reference is RFC 2046 section 5.1. Also see RFC 2387 for
> multipart/related, which is probably what CouchDB will want to use.
>
> It's actually pretty simple, as you can see by looking at some lightweight
> MIME implementations which handle only multipart, e.g.
> http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8/lib/soap/mimemessage.rb?view=markup
And here's a really tiny one (just for multipart HTTP POSTs)
http://www.realityforge.org/articles/2006/03/02/upload-a-file-via-post-with-net-http
A couple of knock-on effects to consider:
- You could allow the option of using multipart/mixed when doing a
multi-document fetch (or even a view). Then when this is combined with
attachments=true, each doc would be a multipart/related nested within
a multipart/mixed wrapper. A bit unusual, but perfectly legal.
- You won't want to calculate an up-front Content-Length: for all this,
so probably best to use chunked transfer encoding.
Regards,
Brian.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Brian Candler <B....@pobox.com>.
On Thu, Feb 26, 2009 at 06:37:58PM -0600, Jeff Hinrichs - DM&T wrote:
> > The major speed up factors when doing this in multipart mime are:
> >
> > 1. Streaming bytes from and to disk for attachments.
> > 2. No Base64 round trip
> > 3. No base64 means less data transferred
> >
> > Seems like I'm missing another one, but those are the biggies.
>
> I knew there had to be more to it than what I was understanding. Any
> chance you could point me to a reference for multipart mime requests?
> I ran a goog this morning but ended up with lots of email oriented
> hits.
The canonical reference is RFC 2046 section 5.1. Also see RFC 2387 for
multipart/related, which is probably what CouchDB will want to use.
It's actually pretty simple, as you can see by looking at some lightweight
MIME implementations which handle only multipart, e.g.
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8/lib/soap/mimemessage.rb?view=markup
Regards,
Brian.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jeff Hinrichs - DM&T <du...@gmail.com>.
On Thu, Feb 26, 2009 at 6:59 PM, Paul Davis <pa...@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 7:58 PM, Paul Davis <pa...@gmail.com> wrote:
>> On Thu, Feb 26, 2009 at 7:37 PM, Jeff Hinrichs - DM&T
>> <du...@gmail.com> wrote:
>>> On Thu, Feb 26, 2009 at 9:47 AM, Paul Davis <pa...@gmail.com> wrote:
>>>> On Thu, Feb 26, 2009 at 8:42 AM, Jeff Hinrichs - DM&T
>>>> <du...@gmail.com> wrote:
>>>>> On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>
>>>>>> On 26 Feb 2009, at 09:03, Brian Candler wrote:
>>>>>>
>>>>>>> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote:
>>>>>>>>>
>>>>>>>>> CouchDB dodges this at present, since you can't download a document
>>>>>>>>> together
>>>>>>>>> with its attachments.
>>>>>>>>
>>>>>>>> what about ?attachments=true or am I misunderstanding you?
>>>>>>>
>>>>>>> This is new to me - such feature doesn't seem to be mentioned at
>>>>>>> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
>>>>>>>
>>>>>>> "When retrieving documents, the attachment's actual data is not included,
>>>>>>> only the metadata. The actual data has to be fetched separately, using a
>>>>>>> special URI."
>>>>>>>
>>>>>>> However I do see "attachments=true" in couch_rep.erl. Is this something
>>>>>>> internal/private for replication?
>>>>>>
>>>>>> This is an omission in the documentation. I added it to the wiki now with
>>>>>> a note that you should not use it :) I think the plan forward is to add an
>>>>>> API
>>>>>> where documents and attachments can be transferred in a single HTTP
>>>>>> request using a multipart mime request. This will speed up replication,
>>>>> Not immediately apparent that this is true, only if mime encode/decode
>>>>> is faster than json encode/decode
>>>>>
>>>>
>>>> The major speed up factors when doing this in multipart mime are:
>>>>
>>>> 1. Streaming bytes from and to disk for attachments.
>>>> 2. No Base64 round trip
>>>> 3. No base64 means less data transferred
>>>>
>>>> Seems like I'm missing another one, but those are the biggies.
>>>
>>> I knew there had to be more to it than what I was understanding. Any
>>> chance you could point me to a reference for multipart mime requests?
>>> I ran a goog this morning but ended up with lots of email oriented
>>> hits.
>>>
>>>> HTH,
>>>> Paul Davis
>>>>
>>>>>> fix handling replication with large attachments and makes it possible to
>>>>>> create a document and a set of attachments without going through
>>>>>> intermediate revisions.
>>>>> I am doing this currently, the recent fix to mochiweb of the 1MB body
>>>>> regression allows one to upload document + attachments in a single
>>>>> revision -- you need to base64 the attachment and set the attributes,
>>>>> but it works. My dump/load code does it quite nicely.
>>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jeff Hinrichs
>>>>>
>>>>
>>> Regards,
>>>
>>> Jeff
>>>
>>
>> MIME (multipurpose internet mail extensions) is originally an email
>> specification. The basic idea is exactly the same for HTTP though in
>> the tradition of RFC's I imagine there are special caveats when used
>> in either context.
>>
>> The wiki looks to have some decent info as well as linked RFC's for
>> different bits.
>>
>> [1] http://en.wikipedia.org/wiki/MIME#Multipart_messages
>>
>> HTH,
>> Paul Davis
>>
>
> Whoops, reply not sent to the list.
>
That explains my misunderstanding, I didn't realize it supported
binary. My encounters to date have always been quoted-printable and
base64. Thanks for the pointer!
Regards,
Jeff Hinrichs
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Feb 26, 2009 at 7:58 PM, Paul Davis <pa...@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 7:37 PM, Jeff Hinrichs - DM&T
> <du...@gmail.com> wrote:
>> On Thu, Feb 26, 2009 at 9:47 AM, Paul Davis <pa...@gmail.com> wrote:
>>> On Thu, Feb 26, 2009 at 8:42 AM, Jeff Hinrichs - DM&T
>>> <du...@gmail.com> wrote:
>>>> On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>
>>>>> On 26 Feb 2009, at 09:03, Brian Candler wrote:
>>>>>
>>>>>> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote:
>>>>>>>>
>>>>>>>> CouchDB dodges this at present, since you can't download a document
>>>>>>>> together
>>>>>>>> with its attachments.
>>>>>>>
>>>>>>> what about ?attachments=true or am I misunderstanding you?
>>>>>>
>>>>>> This is new to me - such feature doesn't seem to be mentioned at
>>>>>> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
>>>>>>
>>>>>> "When retrieving documents, the attachment's actual data is not included,
>>>>>> only the metadata. The actual data has to be fetched separately, using a
>>>>>> special URI."
>>>>>>
>>>>>> However I do see "attachments=true" in couch_rep.erl. Is this something
>>>>>> internal/private for replication?
>>>>>
>>>>> This is an omission in the documentation. I added it to the wiki now with
>>>>> a note that you should not use it :) I think the plan forward is to add an
>>>>> API
>>>>> where documents and attachments can be transferred in a single HTTP
>>>>> request using a multipart mime request. This will speed up replication,
>>>> Not immediately apparent that this is true, only if mime encode/decode
>>>> is faster than json encode/decode
>>>>
>>>
>>> The major speed up factors when doing this in multipart mime are:
>>>
>>> 1. Streaming bytes from and to disk for attachments.
>>> 2. No Base64 round trip
>>> 3. No base64 means less data transferred
>>>
>>> Seems like I'm missing another one, but those are the biggies.
>>
>> I knew there had to be more to it than what I was understanding. Any
>> chance you could point me to a reference for multipart mime requests?
>> I ran a goog this morning but ended up with lots of email oriented
>> hits.
>>
>>> HTH,
>>> Paul Davis
>>>
>>>>> fix handling replication with large attachments and makes it possible to
>>>>> create a document and a set of attachments without going through
>>>>> intermediate revisions.
>>>> I am doing this currently, the recent fix to mochiweb of the 1MB body
>>>> regression allows one to upload document + attachments in a single
>>>> revision -- you need to base64 the attachment and set the attributes,
>>>> but it works. My dump/load code does it quite nicely.
>>>>>
>>>>
>>>> Regards,
>>>>
>>>> Jeff Hinrichs
>>>>
>>>
>> Regards,
>>
>> Jeff
>>
>
> MIME (multipurpose internet mail extensions) is originally an email
> specification. The basic idea is exactly the same for HTTP though in
> the tradition of RFC's I imagine there are special caveats when used
> in either context.
>
> The wiki looks to have some decent info as well as linked RFC's for
> different bits.
>
> [1] http://en.wikipedia.org/wiki/MIME#Multipart_messages
>
> HTH,
> Paul Davis
>
Whoops, reply not sent to the list.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jeff Hinrichs - DM&T <du...@gmail.com>.
On Thu, Feb 26, 2009 at 9:47 AM, Paul Davis <pa...@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 8:42 AM, Jeff Hinrichs - DM&T
> <du...@gmail.com> wrote:
>> On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>> On 26 Feb 2009, at 09:03, Brian Candler wrote:
>>>
>>>> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote:
>>>>>>
>>>>>> CouchDB dodges this at present, since you can't download a document
>>>>>> together
>>>>>> with its attachments.
>>>>>
>>>>> what about ?attachments=true or am I misunderstanding you?
>>>>
>>>> This is new to me - such feature doesn't seem to be mentioned at
>>>> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
>>>>
>>>> "When retrieving documents, the attachment's actual data is not included,
>>>> only the metadata. The actual data has to be fetched separately, using a
>>>> special URI."
>>>>
>>>> However I do see "attachments=true" in couch_rep.erl. Is this something
>>>> internal/private for replication?
>>>
>>> This is an omission in the documentation. I added it to the wiki now with
>>> a note that you should not use it :) I think the plan forward is to add an
>>> API
>>> where documents and attachments can be transferred in a single HTTP
>>> request using a multipart mime request. This will speed up replication,
>> Not immediately apparent that this is true, only if mime encode/decode
>> is faster than json encode/decode
>>
>
> The major speed up factors when doing this in multipart mime are:
>
> 1. Streaming bytes from and to disk for attachments.
> 2. No Base64 round trip
> 3. No base64 means less data transferred
>
> Seems like I'm missing another one, but those are the biggies.
I knew there had to be more to it than what I was understanding. Any
chance you could point me to a reference for multipart mime requests?
I ran a goog this morning but ended up with lots of email oriented
hits.
> HTH,
> Paul Davis
>
>>> fix handling replication with large attachments and makes it possible to
>>> create a document and a set of attachments without going through
>>> intermediate revisions.
>> I am doing this currently, the recent fix to mochiweb of the 1MB body
>> regression allows one to upload document + attachments in a single
>> revision -- you need to base64 the attachment and set the attributes,
>> but it works. My dump/load code does it quite nicely.
>>>
>>
>> Regards,
>>
>> Jeff Hinrichs
>>
>
Regards,
Jeff
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Feb 26, 2009 at 8:42 AM, Jeff Hinrichs - DM&T
<du...@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>> On 26 Feb 2009, at 09:03, Brian Candler wrote:
>>
>>> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote:
>>>>>
>>>>> CouchDB dodges this at present, since you can't download a document
>>>>> together
>>>>> with its attachments.
>>>>
>>>> what about ?attachments=true or am I misunderstanding you?
>>>
>>> This is new to me - such feature doesn't seem to be mentioned at
>>> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
>>>
>>> "When retrieving documents, the attachment's actual data is not included,
>>> only the metadata. The actual data has to be fetched separately, using a
>>> special URI."
>>>
>>> However I do see "attachments=true" in couch_rep.erl. Is this something
>>> internal/private for replication?
>>
>> This is an omission in the documentation. I added it to the wiki now with
>> a note that you should not use it :) I think the plan forward is to add an
>> API
>> where documents and attachments can be transferred in a single HTTP
>> request using a multipart mime request. This will speed up replication,
> Not immediately apparent that this is true, only if mime encode/decode
> is faster than json encode/decode
>
The major speed up factors when doing this in multipart mime are:
1. Streaming bytes from and to disk for attachments.
2. No Base64 round trip
3. No base64 means less data transferred
Seems like I'm missing another one, but those are the biggies.
HTH,
Paul Davis
>> fix handling replication with large attachments and makes it possible to
>> create a document and a set of attachments without going through
>> intermediate revisions.
> I am doing this currently, the recent fix to mochiweb of the 1MB body
> regression allows one to upload document + attachments in a single
> revision -- you need to base64 the attachment and set the attributes,
> but it works. My dump/load code does it quite nicely.
>>
>
> Regards,
>
> Jeff Hinrichs
>
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jeff Hinrichs - DM&T <du...@gmail.com>.
On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 26 Feb 2009, at 09:03, Brian Candler wrote:
>
>> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote:
>>>>
>>>> CouchDB dodges this at present, since you can't download a document
>>>> together
>>>> with its attachments.
>>>
>>> what about ?attachments=true or am I misunderstanding you?
>>
>> This is new to me - such feature doesn't seem to be mentioned at
>> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
>>
>> "When retrieving documents, the attachment's actual data is not included,
>> only the metadata. The actual data has to be fetched separately, using a
>> special URI."
>>
>> However I do see "attachments=true" in couch_rep.erl. Is this something
>> internal/private for replication?
>
> This is an omission in the documentation. I added it to the wiki now with
> a note that you should not use it :) I think the plan forward is to add an
> API
> where documents and attachments can be transferred in a single HTTP
> request using a multipart mime request. This will speed up replication,
Not immediately apparent that this is true, only if mime encode/decode
is faster than json encode/decode
> fix handling replication with large attachments and makes it possible to
> create a document and a set of attachments without going through
> intermediate revisions.
I am doing this currently, the recent fix to mochiweb of the 1MB body
regression allows one to upload document + attachments in a single
revision -- you need to base64 the attachment and set the attributes,
but it works. My dump/load code does it quite nicely.
>
Regards,
Jeff Hinrichs
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
On 26 Feb 2009, at 09:03, Brian Candler wrote:
> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote:
>>> CouchDB dodges this at present, since you can't download a
>>> document together
>>> with its attachments.
>> what about ?attachments=true or am I misunderstanding you?
>
> This is new to me - such feature doesn't seem to be mentioned at
> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
>
> "When retrieving documents, the attachment's actual data is not
> included,
> only the metadata. The actual data has to be fetched separately,
> using a
> special URI."
>
> However I do see "attachments=true" in couch_rep.erl. Is this
> something
> internal/private for replication?
This is an omission in the documentation. I added it to the wiki now
with
a note that you should not use it :) I think the plan forward is to
add an API
where documents and attachments can be transferred in a single HTTP
request using a multipart mime request. This will speed up replication,
fix handling replication with large attachments and makes it possible to
create a document and a set of attachments without going through
intermediate revisions.
Cheers
Jan
--
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Brian Candler <B....@pobox.com>.
On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote:
> > CouchDB dodges this at present, since you can't download a document together
> > with its attachments.
> what about ?attachments=true or am I misunderstanding you?
This is new to me - such feature doesn't seem to be mentioned at
http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
"When retrieving documents, the attachment's actual data is not included,
only the metadata. The actual data has to be fetched separately, using a
special URI."
However I do see "attachments=true" in couch_rep.erl. Is this something
internal/private for replication?
Regards,
Brian.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jeff Hinrichs - DM&T <du...@gmail.com>.
On Wed, Feb 25, 2009 at 2:48 AM, Brian Candler <B....@pobox.com> wrote:
> On Tue, Feb 24, 2009 at 04:51:08PM -0500, Paul Davis wrote:
>> That hadn't occurred to me. I kinda liked the attachments via
>> multipart mime so i was more forcing everything else into that format.
>> At the moment I can't decide which form I prefer. I definitely see
>> sticking to JSON being easier to parse all around, though.
>
> Even if you could read MIME multipart directly using XHR, to get a document
> complete with its attachments, you'd end up with binary (non-Unicode)
> strings in your Javascript.
>
> Ecma-262 says that Strings don't have to be valid Unicode. However CouchDB
> requires attachment uploads to be base64-encoded. Would I be right to say
> this is because of a JSON restriction, rather than a Javascript one?
>
> CouchDB dodges this at present, since you can't download a document together
> with its attachments.
what about ?attachments=true or am I misunderstanding you?
>I don't suppose that much attachment processing takes
> place in Javascript anyway; in normal cases the Javascript creates a URL
> from the attachment name, which the user clicks on to download or view the
> attachment, without JS ever seeing the body.
>
> Regards,
>
> Brian.
>
regards,
Jeff Hinrichs
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Brian Candler <B....@pobox.com>.
On Tue, Feb 24, 2009 at 04:51:08PM -0500, Paul Davis wrote:
> That hadn't occurred to me. I kinda liked the attachments via
> multipart mime so i was more forcing everything else into that format.
> At the moment I can't decide which form I prefer. I definitely see
> sticking to JSON being easier to parse all around, though.
Even if you could read MIME multipart directly using XHR, to get a document
complete with its attachments, you'd end up with binary (non-Unicode)
strings in your Javascript.
Ecma-262 says that Strings don't have to be valid Unicode. However CouchDB
requires attachment uploads to be base64-encoded. Would I be right to say
this is because of a JSON restriction, rather than a Javascript one?
CouchDB dodges this at present, since you can't download a document together
with its attachments. I don't suppose that much attachment processing takes
place in Javascript anyway; in normal cases the Javascript creates a URL
from the attachment name, which the user clicks on to download or view the
attachment, without JS ever seeing the body.
Regards,
Brian.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Feb 24, 2009 at 4:05 PM, Damien Katz <da...@apache.org> wrote:
>
> On Feb 24, 2009, at 2:13 PM, Paul Davis wrote:
>>
>> I'm a fan of the no-metadata-in-documents concept, but there are some
>> issues both philosophical and practical. Philosophically speaking, as
>> pointed out by the HTTP headers thread, we may be abusing headers when
>> we consider some of the more CouchDB specific concepts, I doubt that
>> there's an existing header for everything we'd need.
>>
>> Secondly _attachments and _rev_info are unbounded. I know there are
>> limits to the number of headers in a request I can only assume that
>> some clients might have limits for responses.
>
> Good points.
>
>>
>> The only thought I had that would satisfy most of the interesting bits
>> I've come up against would be to have two response versions: the raw
>> document body as we have now (minus metadata obviously) that includes
>> the very basic _id and _rev in the headers (I'm assuming there are
>> appropriate headers for these). And a second version that is a
>> multipart mime message that has parts corresponding to the doc body,
>> the longer metadata like _revs_info and then one part per attachment.
>> Including the different parts could be optional. And so far that's
>> missing some stuff like listing attachment info without getting the
>> entire body.
>>
>
> Sounds interesting.
>
>> The real kicker is how do we support clients lacking HTTP-fu. For
>> instance, a quick google [1] suggests that XHR probably isn't capable
>> of dealing with multipart messages.
>
> Stupid reality!
>
>> There's an obvious middle ground
>> that could allow different versions to be returned via URL parameters
>> though, and then maybe provide the "all content as multipart mime" as
>> an option.
>
>
> There could be a format where all the metadata is returned in the top level
> json object, and the json body is returned as a body field.
>
That hadn't occurred to me. I kinda liked the attachments via
multipart mime so i was more forcing everything else into that format.
At the moment I can't decide which form I prefer. I definitely see
sticking to JSON being easier to parse all around, though.
On side note that makes me chuckle, going with headers would probably
push the _rev attribute into an Etag header, thus sidestepping the
renaming issue for that part of the API :D
Anyway, I'll let that percolate a bit and read some more of the db and
replication api's to try and get a better handle on all the different
bits that actually touch the _ metadata.
HTH,
Paul Davis
>>
>> Anyway, that's about as far as I've thought through the different issues.
>
> Right. I've alway thought it might be a good idea to do something like this,
> but there are lots of small issues to work through. I hope someone tries,
> I'd like to see if its workable in practice.
>
> -Damien
>
>
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Damien Katz <da...@apache.org>.
On Feb 24, 2009, at 2:13 PM, Paul Davis wrote:
>
> I'm a fan of the no-metadata-in-documents concept, but there are some
> issues both philosophical and practical. Philosophically speaking, as
> pointed out by the HTTP headers thread, we may be abusing headers when
> we consider some of the more CouchDB specific concepts, I doubt that
> there's an existing header for everything we'd need.
>
> Secondly _attachments and _rev_info are unbounded. I know there are
> limits to the number of headers in a request I can only assume that
> some clients might have limits for responses.
Good points.
>
> The only thought I had that would satisfy most of the interesting bits
> I've come up against would be to have two response versions: the raw
> document body as we have now (minus metadata obviously) that includes
> the very basic _id and _rev in the headers (I'm assuming there are
> appropriate headers for these). And a second version that is a
> multipart mime message that has parts corresponding to the doc body,
> the longer metadata like _revs_info and then one part per attachment.
> Including the different parts could be optional. And so far that's
> missing some stuff like listing attachment info without getting the
> entire body.
>
Sounds interesting.
> The real kicker is how do we support clients lacking HTTP-fu. For
> instance, a quick google [1] suggests that XHR probably isn't capable
> of dealing with multipart messages.
Stupid reality!
> There's an obvious middle ground
> that could allow different versions to be returned via URL parameters
> though, and then maybe provide the "all content as multipart mime" as
> an option.
There could be a format where all the metadata is returned in the top
level json object, and the json body is returned as a body field.
>
> Anyway, that's about as far as I've thought through the different
> issues.
Right. I've alway thought it might be a good idea to do something like
this, but there are lots of small issues to work through. I hope
someone tries, I'd like to see if its workable in practice.
-Damien
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Feb 24, 2009 at 1:13 PM, Damien Katz <da...@apache.org> wrote:
> I'll once again state my objection to the newlines, which is actually kind
> of weak.
>
> If we compute the revids deterministically (hash the canonical doc
> contents), then when we return the document back to the client, we can send
> as an integrity hash the same revid, because it is already pre-computed and
> stored, etc. What it could save us is the CPU cycles of computing the hash.
> I think we also get some nice free caching benefits too, but I'm not sure.
> But if we do, it might even save us the disk reads to get the doc to compute
> the hash. The problem is any standardized canonical representation is
> unlikely to included a newline at the end.
>
> Now I'm not even sure this scheme is workable either way, or only workable
> in very special instances which are too rare to be worth it. But if the
> scheme works, then it can simplify the code and make things more efficient,
> which are 2 very good things. However these benefits may never come, and
> we'll not have the newlines anyway. That would suck.
>
> But the problem if we just add the newlines, then later remove them,
> production apps and scripts that rely on that will break and make the change
> is very painful. Or impossible.
>
> So, those are the issues as I see them.
>
> Now the more I think about it, the more I think that unless we move all
> couchdb metadata to the http header, my ideas won't work. Moving everything
> meta to the header is a big change that has some supporters, but someone
> would need to do the work before it could even be considered.
>
> -Damien
>
I'm a fan of the no-metadata-in-documents concept, but there are some
issues both philosophical and practical. Philosophically speaking, as
pointed out by the HTTP headers thread, we may be abusing headers when
we consider some of the more CouchDB specific concepts, I doubt that
there's an existing header for everything we'd need.
Secondly _attachments and _rev_info are unbounded. I know there are
limits to the number of headers in a request I can only assume that
some clients might have limits for responses.
The only thought I had that would satisfy most of the interesting bits
I've come up against would be to have two response versions: the raw
document body as we have now (minus metadata obviously) that includes
the very basic _id and _rev in the headers (I'm assuming there are
appropriate headers for these). And a second version that is a
multipart mime message that has parts corresponding to the doc body,
the longer metadata like _revs_info and then one part per attachment.
Including the different parts could be optional. And so far that's
missing some stuff like listing attachment info without getting the
entire body.
The real kicker is how do we support clients lacking HTTP-fu. For
instance, a quick google [1] suggests that XHR probably isn't capable
of dealing with multipart messages. There's an obvious middle ground
that could allow different versions to be returned via URL parameters
though, and then maybe provide the "all content as multipart mime" as
an option.
Anyway, that's about as far as I've thought through the different issues.
HTH,
Paul Davis
[1] http://groups.google.com/group/mozilla.dev.tech.xml/browse_thread/thread/e1599de6fc31f2e8
> On Feb 24, 2009, at 12:30 PM, Chris Anderson wrote:
>
>> I go to sleep for 8 hours, and this is the thanks I get! ;)
>>
>> But on a more serious note, I think we should pull a hedge fund move,
>> (or maybe quantum entanglement?) and add to the newline patch, some
>> lines that would change the color of the CouchDB logo from red to
>> blue.
>>
>> OK actually - I have a new opinion about the newlines stuff. Since I
>> really don't care all that much, and I don't see a canonical JSON
>> format happening anytime soon, I'm fine with returning newlines at the
>> end of our responses.
>>
>> Some implementation notes:
>>
>> I haven't looked at the patch lately, but I know that there are lots
>> of little places in the code that it will have to touch.
>>
>> Also, and we haven't discussed this nearly as much as we probably
>> should, the implementation of JSONP would be quite similar. To
>> implement JSONP we'll need to do something like this:
>>
>> USER_SPECIFIED_CALLBACK_NAME + "(" + CouchDB's JSON response + ");"
>>
>> So it's like the newline at the end patch, but also at the beginnings...
>>
>> That is all.
>>
>> Chris
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>
>
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Damien Katz <da...@apache.org>.
I'll once again state my objection to the newlines, which is actually
kind of weak.
If we compute the revids deterministically (hash the canonical doc
contents), then when we return the document back to the client, we can
send as an integrity hash the same revid, because it is already pre-
computed and stored, etc. What it could save us is the CPU cycles of
computing the hash. I think we also get some nice free caching
benefits too, but I'm not sure. But if we do, it might even save us
the disk reads to get the doc to compute the hash. The problem is any
standardized canonical representation is unlikely to included a
newline at the end.
Now I'm not even sure this scheme is workable either way, or only
workable in very special instances which are too rare to be worth it.
But if the scheme works, then it can simplify the code and make things
more efficient, which are 2 very good things. However these benefits
may never come, and we'll not have the newlines anyway. That would suck.
But the problem if we just add the newlines, then later remove them,
production apps and scripts that rely on that will break and make the
change is very painful. Or impossible.
So, those are the issues as I see them.
Now the more I think about it, the more I think that unless we move
all couchdb metadata to the http header, my ideas won't work. Moving
everything meta to the header is a big change that has some
supporters, but someone would need to do the work before it could even
be considered.
-Damien
On Feb 24, 2009, at 12:30 PM, Chris Anderson wrote:
> I go to sleep for 8 hours, and this is the thanks I get! ;)
>
> But on a more serious note, I think we should pull a hedge fund move,
> (or maybe quantum entanglement?) and add to the newline patch, some
> lines that would change the color of the CouchDB logo from red to
> blue.
>
> OK actually - I have a new opinion about the newlines stuff. Since I
> really don't care all that much, and I don't see a canonical JSON
> format happening anytime soon, I'm fine with returning newlines at the
> end of our responses.
>
> Some implementation notes:
>
> I haven't looked at the patch lately, but I know that there are lots
> of little places in the code that it will have to touch.
>
> Also, and we haven't discussed this nearly as much as we probably
> should, the implementation of JSONP would be quite similar. To
> implement JSONP we'll need to do something like this:
>
> USER_SPECIFIED_CALLBACK_NAME + "(" + CouchDB's JSON response + ");"
>
> So it's like the newline at the end patch, but also at the
> beginnings...
>
> That is all.
>
> Chris
>
> --
> Chris Anderson
> http://jchris.mfdz.com
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Chris Anderson <jc...@apache.org>.
I go to sleep for 8 hours, and this is the thanks I get! ;)
But on a more serious note, I think we should pull a hedge fund move,
(or maybe quantum entanglement?) and add to the newline patch, some
lines that would change the color of the CouchDB logo from red to
blue.
OK actually - I have a new opinion about the newlines stuff. Since I
really don't care all that much, and I don't see a canonical JSON
format happening anytime soon, I'm fine with returning newlines at the
end of our responses.
Some implementation notes:
I haven't looked at the patch lately, but I know that there are lots
of little places in the code that it will have to touch.
Also, and we haven't discussed this nearly as much as we probably
should, the implementation of JSONP would be quite similar. To
implement JSONP we'll need to do something like this:
USER_SPECIFIED_CALLBACK_NAME + "(" + CouchDB's JSON response + ");"
So it's like the newline at the end patch, but also at the beginnings...
That is all.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
On 24 Feb 2009, at 14:02, Noah Slater wrote:
> On Tue, Feb 24, 2009 at 10:48:31PM +1030, Antony Blakey wrote:
>> On 24/02/2009, at 10:34 PM, Noah Slater wrote:
>>> On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
>>>> I'm a bit confused about this. Excuse me while I tread carefully.
>>>> It
>>>> seems that the community vote is clearly a majority to accept the
>>>> patch.
>>>> If the end result of this vote is that we don't follow that vote
>>>> because
>>>> it's only the PMC vote that counts, doesn't that mean that
>>>> community
>>>> votes are irrelevant?
>>>
>>> Anthony, I am upset that you seem to be wanting to cause trouble
>>> again.
>>
>> It was a question Noah.
>>
>> Your characterization of my intent as being 'to cause trouble', and
>> furthermore 'again', is entirely erroneous.
>
> No, it most certainly was not just a question.
>
> Instead of asking how community votes would be factored into the
> final result,
> you constructed a hypothetical that frames the PMC as a
> dictatorship, doing as
> it pleases regardless of community feedback. You then use this
> hypothetical to
> draw the absurd conclusion that "community votes are irrelevant" and
> then seek
> an explicit refutation.
>
> You have consistently used this style of framing. It seems that you
> presume the
> worst in people and processes instead of giving us the courteous
> benefit of the
> doubt. It has been consistently pointed out to you that this causes
> offence and
> unnecessary friction, and you have been politely asked to think
> about other ways
> of approaching constructive discussion.
+1
Jan
--
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Antony Blakey <an...@gmail.com>.
I'm sure this is of no interest to anyone. I've replied privately.
On 24/02/2009, at 11:32 PM, Noah Slater wrote:
> No, it most certainly was not just a question.
>
> Instead of asking how community votes would be factored into the
> final result,
> you constructed a hypothetical that frames the PMC as a
> dictatorship, doing as
> it pleases regardless of community feedback. You then use this
> hypothetical to
> draw the absurd conclusion that "community votes are irrelevant" and
> then seek
> an explicit refutation.
>
> You have consistently used this style of framing. It seems that you
> presume the
> worst in people and processes instead of giving us the courteous
> benefit of the
> doubt. It has been consistently pointed out to you that this causes
> offence and
> unnecessary friction, and you have been politely asked to think
> about other ways
> of approaching constructive discussion.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
All that is required for evil to triumph is that good men do nothing.
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Tue, Feb 24, 2009 at 10:48:31PM +1030, Antony Blakey wrote:
> On 24/02/2009, at 10:34 PM, Noah Slater wrote:
>> On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
>>> I'm a bit confused about this. Excuse me while I tread carefully. It
>>> seems that the community vote is clearly a majority to accept the
>>> patch.
>>> If the end result of this vote is that we don't follow that vote
>>> because
>>> it's only the PMC vote that counts, doesn't that mean that community
>>> votes are irrelevant?
>>
>> Anthony, I am upset that you seem to be wanting to cause trouble
>> again.
>
> It was a question Noah.
>
> Your characterization of my intent as being 'to cause trouble', and
> furthermore 'again', is entirely erroneous.
No, it most certainly was not just a question.
Instead of asking how community votes would be factored into the final result,
you constructed a hypothetical that frames the PMC as a dictatorship, doing as
it pleases regardless of community feedback. You then use this hypothetical to
draw the absurd conclusion that "community votes are irrelevant" and then seek
an explicit refutation.
You have consistently used this style of framing. It seems that you presume the
worst in people and processes instead of giving us the courteous benefit of the
doubt. It has been consistently pointed out to you that this causes offence and
unnecessary friction, and you have been politely asked to think about other ways
of approaching constructive discussion.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Antony Blakey <an...@gmail.com>.
On 24/02/2009, at 10:34 PM, Noah Slater wrote:
> On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
>> I'm a bit confused about this. Excuse me while I tread carefully. It
>> seems that the community vote is clearly a majority to accept the
>> patch.
>> If the end result of this vote is that we don't follow that vote
>> because
>> it's only the PMC vote that counts, doesn't that mean that community
>> votes are irrelevant?
>
> Anthony, I am upset that you seem to be wanting to cause trouble
> again.
It was a question Noah.
Your characterization of my intent as being 'to cause trouble', and
furthermore 'again', is entirely erroneous.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Every task involves constraint,
Solve the thing without complaint;
There are magic links and chains
Forged to loose our rigid brains.
Structures, structures, though they bind,
Strangely liberate the mind.
-- James Fallen
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re:
VOTE: accept newline patch into CouchDB for 0.9)
Posted by Noah Slater <ns...@apache.org>.
On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
> I'm a bit confused about this. Excuse me while I tread carefully. It
> seems that the community vote is clearly a majority to accept the patch.
> If the end result of this vote is that we don't follow that vote because
> it's only the PMC vote that counts, doesn't that mean that community
> votes are irrelevant?
Anthony, I am upset that you seem to be wanting to cause trouble again.
If you look back at my original email, you will find:
* The community and PMC have decided to open this issue back up for
discussion, with the proviso that we complete our final decision before
releasing 0.9 -- which means another vote in a week or so. Heh.
* The community was strongly in favour of accepting the patch, but the PMC was
almost completely split down the middle, with a slightly preference for not
accepting the patch.
Clearly the community votes are not irrelevant, otherwise I would not have
listed them or taken them into account. Apache is a meritocracy, meaning that
some votes carry more weight than others. When the PMC votes so heavily for
further discussion in the light of a strong community support, I hardly see that
you could suggest any other outcome than to open up the discussion.
Moreover, if you had actually bothered to read the rules for Apache voting on
code modification you would know that Chris Anderson and Jan Lehnardt had vetoed
the patch, meaning that it cannot possibly be accepted.
http://www.apache.org/foundation/voting.html
Best.
--
Noah Slater, http://tumbolia.org/nslater
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Damien Katz <da...@apache.org>.
On Feb 24, 2009, at 6:44 AM, Antony Blakey wrote:
>
> On 23/02/2009, at 3:17 AM, Jan Lehnardt wrote:
>
>> Collecting:
>>
>> On 23 Jan 2009, at 23:42, Noah Slater wrote:
>>> * Accept the patch (or a modified version) and add newline chars
>>
>> +1: 7 (2 binding)
>> -1: 3 (2 binding)
>>
>>> * Reject the patch (and any modified version) and do not add
>>> newlines chars
>>
>> +1: 3 (2 binding)
>> -1: 4
>>
>>
>>> * Further discussion, to be decided before we release 0.9
>>
>> +1: 1 (1 binding)
>> -1: 1 (1 binding)
>>
>>> * Further discussion, to be decided after we release 0.9
>>
>> +1:
>> -1: 2 (2 binding)
>>
>> --
>>
>> It looks like we have a draw with weigh-in from the community
>> on a +1 to accept the patch.
>>
>> We need more discussion here.
>
> I'm a bit confused about this. Excuse me while I tread carefully. It
> seems that the community vote is clearly a majority to accept the
> patch. If the end result of this vote is that we don't follow that
> vote because it's only the PMC vote that counts, doesn't that mean
> that community votes are irrelevant?
It means "We need more discussion here". Getting consensus is
important, especially when the main development contributors have
disagreements.
-Damien
Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Antony Blakey <an...@gmail.com>.
On 23/02/2009, at 3:17 AM, Jan Lehnardt wrote:
> Collecting:
>
> On 23 Jan 2009, at 23:42, Noah Slater wrote:
>> * Accept the patch (or a modified version) and add newline chars
>
> +1: 7 (2 binding)
> -1: 3 (2 binding)
>
>> * Reject the patch (and any modified version) and do not add
>> newlines chars
>
> +1: 3 (2 binding)
> -1: 4
>
>
>> * Further discussion, to be decided before we release 0.9
>
> +1: 1 (1 binding)
> -1: 1 (1 binding)
>
>> * Further discussion, to be decided after we release 0.9
>
> +1:
> -1: 2 (2 binding)
>
> --
>
> It looks like we have a draw with weigh-in from the community
> on a +1 to accept the patch.
>
> We need more discussion here.
I'm a bit confused about this. Excuse me while I tread carefully. It
seems that the community vote is clearly a majority to accept the
patch. If the end result of this vote is that we don't follow that
vote because it's only the PMC vote that counts, doesn't that mean
that community votes are irrelevant?
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
A priest, a minister and a rabbi walk into a bar. The bartender says
"What is this, a joke?"
[RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Posted by Jan Lehnardt <ja...@apache.org>.
Collecting:
On 23 Jan 2009, at 23:42, Noah Slater wrote:
> * Accept the patch (or a modified version) and add newline chars
+1: 7 (2 binding)
-1: 3 (2 binding)
> * Reject the patch (and any modified version) and do not add
> newlines chars
+1: 3 (2 binding)
-1: 4
> * Further discussion, to be decided before we release 0.9
+1: 1 (1 binding)
-1: 1 (1 binding)
> * Further discussion, to be decided after we release 0.9
+1:
-1: 2 (2 binding)
--
It looks like we have a draw with weigh-in from the community
on a +1 to accept the patch.
We need more discussion here.
--
I noticed that one reason is the CLI-friendliness of the appended
newline.
I created "couchcurl", a stupid-simple wrapper around curl that adds
a newline:
http://github.com/janl/couchcurl/tree/master
I wanted this tool for a long time and as you can see in the TODO
section, this is indeed quite useful if you can specify default server
names and port numbers so you could run
couchcurl -X PUT /database-name
instead of
curl -X PUT http://127.0.0.1:5984/database-name
I hope to get more people to help adding more features.
For the moment I like to keep this in sh-script only for maximum
compatibility, but I could be persuaded to rewrite it in python or
possibly include it in the CouchApp project. Alternatively, we
could bundle it with CouchDB.
I understand that this does not counter all objections in the +1 camp,
but maybe we can get more support on the -1 camp through the
community :)
Cheers
Jan
--
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jan 23, 2009 at 05:45:25PM -0500, Dean Landolt wrote:
> > * Accept the patch (or a modified version) and add newline chars
> >
> > * Reject the patch (and any modified version) and do not add newlines
> > chars
> >
> > * Further discussion, to be decided before we release 0.9
> >
> > * Further discussion, to be decided after we release 0.9
> >
> >
> +1
Could you be more specific which option you were voting on? Thanks!
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Dean Landolt <de...@deanlandolt.com>.
On Fri, Jan 23, 2009 at 5:42 PM, Noah Slater <ns...@apache.org> wrote:
> Hey,
>
> I've been simultaneously looking forward to and dreading this, but here
> goes.
>
> We need to decide a resolution for COUCHDB-107:
>
> End JSON responses with newline char
>
> This ticket has a patch, and it's been discussed to death on the mailing
> list.
>
> The summary of the arguments are:
>
> * PRO: It is POSIXly correct and improves usability from the command line
>
> * CON: It might not conform to a future canonical JSON representation
>
> Even though this seems to be the colour of our very own bikeshed, we still
> need
> to paint the damn thing, so I think it's best to decide the colour once and
> for
> all and get on with releasing 0.9 along with any other API changes.
>
> Along those lines, I hereby present four options and an informal vote:
>
> * Accept the patch (or a modified version) and add newline chars
>
> * Reject the patch (and any modified version) and do not add newlines
> chars
>
> * Further discussion, to be decided before we release 0.9
>
> * Further discussion, to be decided after we release 0.9
>
>
+1
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Paul Davis <pa...@gmail.com>.
On Fri, Jan 23, 2009 at 5:42 PM, Noah Slater <ns...@apache.org> wrote:
> Hey,
>
> I've been simultaneously looking forward to and dreading this, but here goes.
>
> We need to decide a resolution for COUCHDB-107:
>
> End JSON responses with newline char
>
> This ticket has a patch, and it's been discussed to death on the mailing list.
>
> The summary of the arguments are:
>
> * PRO: It is POSIXly correct and improves usability from the command line
>
> * CON: It might not conform to a future canonical JSON representation
>
> Even though this seems to be the colour of our very own bikeshed, we still need
> to paint the damn thing, so I think it's best to decide the colour once and for
> all and get on with releasing 0.9 along with any other API changes.
>
> Along those lines, I hereby present four options and an informal vote:
>
> * Accept the patch (or a modified version) and add newline chars
>
> * Reject the patch (and any modified version) and do not add newlines chars
>
> * Further discussion, to be decided before we release 0.9
>
> * Further discussion, to be decided after we release 0.9
>
> Thanks,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Accept patch:
+1
Reject patch:
-1
Discuss before 0.9
-1
Discuss after 0.9
-1
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Jan Lehnardt <ja...@apache.org>.
On 23 Jan 2009, at 23:42, Noah Slater wrote:
> Along those lines, I hereby present four options and an informal vote:
When do we get to do the formal vote? :)
> * Accept the patch (or a modified version) and add newline chars
-1
> * Reject the patch (and any modified version) and do not add
> newlines chars
+1
> * Further discussion, to be decided before we release 0.9
0
> * Further discussion, to be decided after we release 0.9
-1
Cheers
Jan
--
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
Oops, I forgot to vote on them all!
On Fri, Jan 23, 2009 at 10:42:13PM +0000, Noah Slater wrote:
> * Accept the patch (or a modified version) and add newline chars
+1
> * Reject the patch (and any modified version) and do not add newlines chars
-1
> * Further discussion, to be decided before we release 0.9
+0
> * Further discussion, to be decided after we release 0.9
-0
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Jan 26, 2009 at 6:14 PM, Antony Blakey <an...@gmail.com> wrote:
>
> On 27/01/2009, at 12:34 PM, Chris Anderson wrote:
>
>> Which is why I think it makes a good critique of validation.
>
> No way! Validation is also about accessibility, and conformance to
> specifications ensures things are future-proof, and allows for independent
> development.
Validation has its place. The Google homepage is perhaps the exception
that proves the rule.
I have no idea how it handles for accessibility, but I'll assume it
the answer is good. What I like about it is the notion that leaving
out " chars has a measurable effect on the planet's electricity bill.
--
Chris Anderson
http://jchris.mfdz.com
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Antony Blakey <an...@gmail.com>.
On 27/01/2009, at 12:34 PM, Chris Anderson wrote:
> Which is why I think it makes a good critique of validation.
No way! Validation is also about accessibility, and conformance to
specifications ensures things are future-proof, and allows for
independent development.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
He who would make his own liberty secure, must guard even his enemy
from repression.
-- Thomas Paine
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Jan 26, 2009 at 5:35 PM, Dean Landolt <de...@deanlandolt.com> wrote:
> On Mon, Jan 26, 2009 at 7:35 PM, Chris Anderson <jc...@apache.org> wrote:
>
>> On Mon, Jan 26, 2009 at 4:27 PM, Noah Slater <ns...@apache.org> wrote:
>> > On Mon, Jan 26, 2009 at 04:05:38PM -0800, Chris Anderson wrote:
>> >> This probably isn't the place to get into it, but I've always sort of
>> >> admired how the Google front page doesn't validate.
>> >
>> > I wonder if doing valid HTML could save them a few bytes?
>>
>> I haven't looked at it lately, but my impression last time was that
>> they started with valid markup, and then had an iterative process
>> remove random characters, keeping any versions that still "work" on
>> their set of supported browsers.
>
>
> I always thought Google's set of supported browsers was *all* browsers.
>
Which is why I think it makes a good critique of validation.
--
Chris Anderson
http://jchris.mfdz.com
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Dean Landolt <de...@deanlandolt.com>.
On Mon, Jan 26, 2009 at 7:35 PM, Chris Anderson <jc...@apache.org> wrote:
> On Mon, Jan 26, 2009 at 4:27 PM, Noah Slater <ns...@apache.org> wrote:
> > On Mon, Jan 26, 2009 at 04:05:38PM -0800, Chris Anderson wrote:
> >> This probably isn't the place to get into it, but I've always sort of
> >> admired how the Google front page doesn't validate.
> >
> > I wonder if doing valid HTML could save them a few bytes?
>
> I haven't looked at it lately, but my impression last time was that
> they started with valid markup, and then had an iterative process
> remove random characters, keeping any versions that still "work" on
> their set of supported browsers.
I always thought Google's set of supported browsers was *all* browsers.
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Jan 26, 2009 at 4:27 PM, Noah Slater <ns...@apache.org> wrote:
> On Mon, Jan 26, 2009 at 04:05:38PM -0800, Chris Anderson wrote:
>> This probably isn't the place to get into it, but I've always sort of
>> admired how the Google front page doesn't validate.
>
> I wonder if doing valid HTML could save them a few bytes?
I haven't looked at it lately, but my impression last time was that
they started with valid markup, and then had an iterative process
remove random characters, keeping any versions that still "work" on
their set of supported browsers.
>
> I've always considered it Google's way of saying "fuck you" to the Web.
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
--
Chris Anderson
http://jchris.mfdz.com
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Mon, Jan 26, 2009 at 04:05:38PM -0800, Chris Anderson wrote:
> This probably isn't the place to get into it, but I've always sort of
> admired how the Google front page doesn't validate.
I wonder if doing valid HTML could save them a few bytes?
I've always considered it Google's way of saying "fuck you" to the Web.
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Jan 26, 2009 at 3:07 PM, Noah Slater <ns...@apache.org> wrote:
> On Mon, Jan 26, 2009 at 01:09:00PM -0800, Chris Anderson wrote:
>> A survey: none of Google, Yahoo, Twitter, Flickr have a newline at the
>> end of their responses.
>
> Argument ad populum isn't very useful on the Web. Heh.
>
> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2F
>
This probably isn't the place to get into it, but I've always sort of
admired how the Google front page doesn't validate.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Mon, Jan 26, 2009 at 01:09:00PM -0800, Chris Anderson wrote:
> A survey: none of Google, Yahoo, Twitter, Flickr have a newline at the
> end of their responses.
Argument ad populum isn't very useful on the Web. Heh.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2F
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Chris Anderson <jc...@apache.org>.
A survey: none of Google, Yahoo, Twitter, Flickr have a newline at the
end of their responses.
curl 'http://www.google.com/calendar/feeds/developer-calendar@google.com/public/full?alt=json&orderby=starttime&max-results=15&singleevents=true&sortorder=ascending&futureevents=true'
curl http://search.twitter.com/search.json?q=json
curl 'http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&query=Madonna&output=json'
curl 'http://www.flickr.com/services/rest/?method=flickr.test.echo&format=json&api_key=eaa28d55e3da54f957a16921f450a0aa'
I'd keep searching to find one that does do newlines, but it felt futile.
You can get a newline from curl like this:
curl -w\\n http://search.twitter.com/search.json?q=json
* Accept the patch (or a modified version) and add newline chars
-1
* Reject the patch (and any modified version) and do not add newlines chars
+1
* Further discussion, to be decided before we release 0.9
+0
* Further discussion, to be decided after we release 0.9
-0
--
Chris Anderson
http://jchris.mfdz.com
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Mon, Jan 26, 2009 at 12:45:11PM -0500, Damien Katz wrote:
> Can we can remove them later if we need to?
The same objection applies in reverse...
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Damien Katz <da...@apache.org>.
Can we can remove them later if we need to?
-Damien
On Jan 26, 2009, at 12:36 PM, Noah Slater wrote:
> On Mon, Jan 26, 2009 at 12:28:26PM -0500, Damien Katz wrote:
>> I think we shouldn't end documents with newlines, because a canonical
>> representation of json won't included a trailing newline, which can
>> cause complications with end to end integrity checks.
>
> There is no canonical JSON representation specification. Any
> discussion about
> what would or would not compose a canonical JSON document is pure
> speculation at
> this point. Even if a canonical JSON representation did exist, and
> didn't
> include the final newline, I still agree with Antony's point that
> this can be
> regarded as a transport issue. I don't think it's going to be a
> problem.
>
> --
> Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Mon, Jan 26, 2009 at 12:28:26PM -0500, Damien Katz wrote:
> I think we shouldn't end documents with newlines, because a canonical
> representation of json won't included a trailing newline, which can
> cause complications with end to end integrity checks.
There is no canonical JSON representation specification. Any discussion about
what would or would not compose a canonical JSON document is pure speculation at
this point. Even if a canonical JSON representation did exist, and didn't
include the final newline, I still agree with Antony's point that this can be
regarded as a transport issue. I don't think it's going to be a problem.
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Damien Katz <da...@apache.org>.
Sorry, I guess I should just vote to let you guys put it in and later
if we have to take it out, we just do. And we break whatever code is
relying on those newlines.
Another option is to have newlines everywhere except for after
document GETs, which would satisfy my objections.
-Damien
On Jan 26, 2009, at 12:28 PM, Damien Katz wrote:
> I think we shouldn't end documents with newlines, because a
> canonical representation of json won't included a trailing newline,
> which can cause complications with end to end integrity checks.
>
> -Damien
>
>
>> Along those lines, I hereby present four options and an informal
>> vote:
>>
>> * Accept the patch (or a modified version) and add newline chars
>
> +0
>
>> * Reject the patch (and any modified version) and do not add
>> newlines chars
>
> +0
>
>> * Further discussion, to be decided before we release 0.9
>
> +1
>
>> * Further discussion, to be decided after we release 0.9
>
>
>
> On Jan 26, 2009, at 7:21 AM, Noah Slater wrote:
>
>> On Mon, Jan 26, 2009 at 01:07:26PM +0100, Christopher Lenz wrote:
>>> On 23.01.2009, at 23:42, Noah Slater wrote:
>>>> We need to decide a resolution for COUCHDB-107:
>>>>
>>>> End JSON responses with newline char
>>>>
>>>> This ticket has a patch, and it's been discussed to death on the
>>>> mailing list.
>>>
>>> FYI, I uploaded a version of the patch updated to work with trunk.
>>
>> Thanks for this!
>>
>> I would like to see votes from the other PMC members please. :)
>>
>> --
>> Noah Slater, http://tumbolia.org/nslater
>
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Damien Katz <da...@apache.org>.
I think we shouldn't end documents with newlines, because a canonical
representation of json won't included a trailing newline, which can
cause complications with end to end integrity checks.
-Damien
> Along those lines, I hereby present four options and an informal vote:
>
> * Accept the patch (or a modified version) and add newline chars
+0
> * Reject the patch (and any modified version) and do not add
> newlines chars
+0
> * Further discussion, to be decided before we release 0.9
+1
> * Further discussion, to be decided after we release 0.9
On Jan 26, 2009, at 7:21 AM, Noah Slater wrote:
> On Mon, Jan 26, 2009 at 01:07:26PM +0100, Christopher Lenz wrote:
>> On 23.01.2009, at 23:42, Noah Slater wrote:
>>> We need to decide a resolution for COUCHDB-107:
>>>
>>> End JSON responses with newline char
>>>
>>> This ticket has a patch, and it's been discussed to death on the
>>> mailing list.
>>
>> FYI, I uploaded a version of the patch updated to work with trunk.
>
> Thanks for this!
>
> I would like to see votes from the other PMC members please. :)
>
> --
> Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Mon, Jan 26, 2009 at 01:07:26PM +0100, Christopher Lenz wrote:
> On 23.01.2009, at 23:42, Noah Slater wrote:
>> We need to decide a resolution for COUCHDB-107:
>>
>> End JSON responses with newline char
>>
>> This ticket has a patch, and it's been discussed to death on the
>> mailing list.
>
> FYI, I uploaded a version of the patch updated to work with trunk.
Thanks for this!
I would like to see votes from the other PMC members please. :)
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Christopher Lenz <cm...@gmx.de>.
On 23.01.2009, at 23:42, Noah Slater wrote:
> We need to decide a resolution for COUCHDB-107:
>
> End JSON responses with newline char
>
> This ticket has a patch, and it's been discussed to death on the
> mailing list.
FYI, I uploaded a version of the patch updated to work with trunk.
> Along those lines, I hereby present four options and an informal vote:
>
> * Accept the patch (or a modified version) and add newline chars
+1
> * Reject the patch (and any modified version) and do not add
> newlines chars
-0
> * Further discussion, to be decided before we release 0.9
+0
> * Further discussion, to be decided after we release 0.9
+0
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jan 23, 2009 at 10:42:13PM +0000, Noah Slater wrote:
> * Accept the patch (or a modified version) and add newline chars
+1
--
Noah Slater, http://tumbolia.org/nslater
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Jan 31, 2009 at 11:07 PM, Zachary Zolton
<za...@gmail.com> wrote:
> For the visual annoyance when using CURL:
> +1 on the newlines
>
This more a bug in curl or the client than anything else. Some other
client just display results on another lines. Try mine for example
(restcli from py-restclient).
* Accept the patch (or a modified version) and add newline chars
-1
* Reject the patch (and any modified version) and do not add newlines chars
+1
* Further discussion, to be decided before we release 0.9
0
* Further discussion, to be decided after we release 0.9
0
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Zachary Zolton <za...@gmail.com>.
For the visual annoyance when using CURL:
+1 on the newlines
On Sat, Jan 31, 2009 at 3:42 PM, Brian Candler <B....@pobox.com> wrote:
> +1 for the patch, namely, adding a single newline at the end of all
> couchdb-generated JSON documents and responses.
>
> Pros:
> - more convenient for command-line HTTP client use
> - more convenient for saving and editing documents off-line
> - more convenient for concatenating multiple responses into a single file
>
> Cons:
> - miniscule bandwidth penalty
> - err, that's it
>
> Any conformant(*) JSON parser will accept the newline, and in any case we
> already insert some arbitary newlines within certain query responses, so we
> are relying on clients having this capability.
>
> I don't think HTTP specs are important here. This is application/json, not
> text/json. In any case we may return JSON with arbitrarily long line
> lengths.
>
> Having the newline is just a feature which (IMO) can make couchdb data a
> little friendlier for its consumers.
>
> One might argue whether it should be \n or \r\n though :-(
>
> Regards,
>
> Brian.
>
> (*) www.json.org says "Whitespace can be inserted between any pair of
> tokens", without making it clear if end-of-file is a token, but RFC 4627 is
> much clearer.
>
Re: VOTE: accept newline patch into CouchDB for 0.9
Posted by Brian Candler <B....@pobox.com>.
+1 for the patch, namely, adding a single newline at the end of all
couchdb-generated JSON documents and responses.
Pros:
- more convenient for command-line HTTP client use
- more convenient for saving and editing documents off-line
- more convenient for concatenating multiple responses into a single file
Cons:
- miniscule bandwidth penalty
- err, that's it
Any conformant(*) JSON parser will accept the newline, and in any case we
already insert some arbitary newlines within certain query responses, so we
are relying on clients having this capability.
I don't think HTTP specs are important here. This is application/json, not
text/json. In any case we may return JSON with arbitrarily long line
lengths.
Having the newline is just a feature which (IMO) can make couchdb data a
little friendlier for its consumers.
One might argue whether it should be \n or \r\n though :-(
Regards,
Brian.
(*) www.json.org says "Whitespace can be inserted between any pair of
tokens", without making it clear if end-of-file is a token, but RFC 4627 is
much clearer.