Re: Proposed couch hack in November or December
On Friday, 27 September 2013 at 18:56, Dave Cottlehuber wrote: Depending on dates I'm up for it. Be more specific. It's my birthday on the 4th so want to be home with the family then, otherwise December is good. Think the dates I saw go past were fine... Oh and bring some Olde Speckled Hen or similar while you're at it ;-). Noted.
[jira] [Assigned] (COUCHDB-1898) Redesign documents to match mainsite/fauxton style
[ https://issues.apache.org/jira/browse/COUCHDB-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin reassigned COUCHDB-1898: - Assignee: Alexander Shorin Redesign documents to match mainsite/fauxton style -- Key: COUCHDB-1898 URL: https://issues.apache.org/jira/browse/COUCHDB-1898 Project: CouchDB Issue Type: Improvement Components: Documentation Reporter: Alexander Shorin Assignee: Alexander Shorin ReadTheDocs style is nice, but since we already have two web resources with quite similar design idea, why docs should looks so different? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (COUCHDB-1898) Redesign documents to match mainsite/fauxton style
Alexander Shorin created COUCHDB-1898: - Summary: Redesign documents to match mainsite/fauxton style Key: COUCHDB-1898 URL: https://issues.apache.org/jira/browse/COUCHDB-1898 Project: CouchDB Issue Type: Improvement Components: Documentation Reporter: Alexander Shorin ReadTheDocs style is nice, but since we already have two web resources with quite similar design idea, why docs should looks so different? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (COUCHDB-1899) Direct Fauxton API/Config references to the docs
[ https://issues.apache.org/jira/browse/COUCHDB-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin reassigned COUCHDB-1899: - Assignee: Alexander Shorin Direct Fauxton API/Config references to the docs Key: COUCHDB-1899 URL: https://issues.apache.org/jira/browse/COUCHDB-1899 Project: CouchDB Issue Type: Improvement Components: Documentation, Fauxton Reporter: Alexander Shorin Assignee: Alexander Shorin Make API reference under API URL button leads to the specific HTTP API reference section at docs, depending on current raw CouchDB URL. Similar improvement for the configuration options. Keeping two different things within single issue since there would be quite similar code for both (HTTP API reference links would have some generics though). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (COUCHDB-1899) Direct Fauxton API/Config references to the docs
Alexander Shorin created COUCHDB-1899: - Summary: Direct Fauxton API/Config references to the docs Key: COUCHDB-1899 URL: https://issues.apache.org/jira/browse/COUCHDB-1899 Project: CouchDB Issue Type: Improvement Components: Documentation, Fauxton Reporter: Alexander Shorin Make API reference under API URL button leads to the specific HTTP API reference section at docs, depending on current raw CouchDB URL. Similar improvement for the configuration options. Keeping two different things within single issue since there would be quite similar code for both (HTTP API reference links would have some generics though). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (COUCHDB-1900) CouchDB Practical Tutorial
Alexander Shorin created COUCHDB-1900: - Summary: CouchDB Practical Tutorial Key: COUCHDB-1900 URL: https://issues.apache.org/jira/browse/COUCHDB-1900 Project: CouchDB Issue Type: Improvement Components: Documentation Reporter: Alexander Shorin Provide fluid sequential CouchDB tutorial that covers all or most CouchDB features and helps users to meet with them incrementally. Currently docs are sux in question of How I do X?. Instead of this, there are a lot of stuff about How Y works at quite high abstraction level. The reality is so, that nobody wastes his time to read the docs and prefers to see some practical example that solves similar problem. And I think that such tutorial would be very useful and may become the connecting link for all other documentation articles. Inspired by [RethinkDB cookbook|http://www.rethinkdb.com/docs/cookbook/] and questions on IRC about how to write update functions etc. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COUCHDB-1521) multipart parser gets multiple attachments mixed up
[ https://issues.apache.org/jira/browse/COUCHDB-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781678#comment-13781678 ] Dave Cottlehuber commented on COUCHDB-1521: --- [~rnewson] [~janl] am I right that this hasn't been addressed in the various multipart patches that already went through? multipart parser gets multiple attachments mixed up --- Key: COUCHDB-1521 URL: https://issues.apache.org/jira/browse/COUCHDB-1521 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Jens Alfke Assignee: Randall Leeds When receiving a document PUT in multipart format, CouchDB gets the attachments and MIME parts mixed up. Instead of looking at the headers of a MIME part to identify which attachment it is (most likely by using the 'filename' property of the 'Content-Disposition:' header), it processes the attachments according to the order in which their metadata objects appear in the JSON body's '_attachments:' object. The problem with this is that JSON objects (dictionaries) are _not_ ordered collections. I know that Erlang's implementation of them (as linked lists of key/value pairs) happens to be ordered, and I think some JavaScript implementations have the side effect of preserving order; but in many languages these are implemented as hash tables and genuinely unordered. This means that when a program written in such a language converts a native object to JSON, it has no control over (and probably no knowledge of) the order in which the keys of the JSON object are written out. This makes it impossible to then write the attachments in the same order. The only workaround seems to be for the program to implement its own custom JSON encoder just so that it can write object keys in a known order (probably sorted), which then enables it to write the attachment bodies in the same order. NOTE: This is the flip side of COUCHDB-1368 which I filed last year; that bug has to do with the same ordering issue when CouchDB _generates_ multipart responses (and presents similar problems for clients not written in Erlang.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COUCHDB-1521) multipart parser gets multiple attachments mixed up
[ https://issues.apache.org/jira/browse/COUCHDB-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781736#comment-13781736 ] Jan Lehnardt commented on COUCHDB-1521: --- correct, has not been addressed. multipart parser gets multiple attachments mixed up --- Key: COUCHDB-1521 URL: https://issues.apache.org/jira/browse/COUCHDB-1521 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Jens Alfke Assignee: Randall Leeds When receiving a document PUT in multipart format, CouchDB gets the attachments and MIME parts mixed up. Instead of looking at the headers of a MIME part to identify which attachment it is (most likely by using the 'filename' property of the 'Content-Disposition:' header), it processes the attachments according to the order in which their metadata objects appear in the JSON body's '_attachments:' object. The problem with this is that JSON objects (dictionaries) are _not_ ordered collections. I know that Erlang's implementation of them (as linked lists of key/value pairs) happens to be ordered, and I think some JavaScript implementations have the side effect of preserving order; but in many languages these are implemented as hash tables and genuinely unordered. This means that when a program written in such a language converts a native object to JSON, it has no control over (and probably no knowledge of) the order in which the keys of the JSON object are written out. This makes it impossible to then write the attachments in the same order. The only workaround seems to be for the program to implement its own custom JSON encoder just so that it can write object keys in a known order (probably sorted), which then enables it to write the attachment bodies in the same order. NOTE: This is the flip side of COUCHDB-1368 which I filed last year; that bug has to do with the same ordering issue when CouchDB _generates_ multipart responses (and presents similar problems for clients not written in Erlang.) -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [1.5.0] Release proposal
I just pushed a branch remove-e4x-tests that removes all traces of E4X (which we deprecated in 1.3.0 / last year). How does everyone feel about getting that into 1.5? E4X would remain working as long as the linked against SpiderMonkey supports it, we’d just not guarantee it anymore. Best Jan -- On Sep 25, 2013, at 17:30 , Dirkjan Ochtman dirk...@ochtman.nl wrote: Hi all, We're quickly getting towards the end of this release cycle. I'll be your RM again; ideally I'd get an artefact out on October 3, as I'm leaving for a few days after that. Some things on the table: - Docs work: we'll be shipping Alexander's branch (whether he wants to or not ;)) - Fauxton: Fauxton team to discuss if it can (finally!) ship as experimental - Plugins? (Jan will look after this) - NodeJS stuff? (#1894, Jan will look after this, too) Please check out issues scheduled for 1.5.0: https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%221.5.0%22%20AND%20project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Scheduling other things for 1.5.0 is also allowed. :) I won't be around for the meeting this evening, so please discuss issues amongst yourselves for my later consideration through the notes. I will also be attempting to streamline the release process somewhat, to make it less time-intensive on the part of the release manager. Cheers, Dirkjan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [1.5.0] Release proposal
+1 On Mon, Sep 30, 2013 at 12:18 PM, Jan Lehnardt j...@apache.org wrote: I just pushed a branch remove-e4x-tests that removes all traces of E4X (which we deprecated in 1.3.0 / last year). How does everyone feel about getting that into 1.5? E4X would remain working as long as the linked against SpiderMonkey supports it, we’d just not guarantee it anymore. Best Jan -- On Sep 25, 2013, at 17:30 , Dirkjan Ochtman dirk...@ochtman.nl wrote: Hi all, We're quickly getting towards the end of this release cycle. I'll be your RM again; ideally I'd get an artefact out on October 3, as I'm leaving for a few days after that. Some things on the table: - Docs work: we'll be shipping Alexander's branch (whether he wants to or not ;)) - Fauxton: Fauxton team to discuss if it can (finally!) ship as experimental - Plugins? (Jan will look after this) - NodeJS stuff? (#1894, Jan will look after this, too) Please check out issues scheduled for 1.5.0: https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%221.5.0%22%20AND%20project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Scheduling other things for 1.5.0 is also allowed. :) I won't be around for the meeting this evening, so please discuss issues amongst yourselves for my later consideration through the notes. I will also be attempting to streamline the release process somewhat, to make it less time-intensive on the part of the release manager. Cheers, Dirkjan
Re: [1.5.0] Release proposal
On Mon, Sep 30, 2013 at 7:18 PM, Jan Lehnardt j...@apache.org wrote: I just pushed a branch remove-e4x-tests that removes all traces of E4X (which we deprecated in 1.3.0 / last year). How does everyone feel about getting that into 1.5? +1. Can you formulate something for the changelog? Either put it in the docs or just dump it here and I'll integrate it. Cheers, Dirkjan
