Agreed. Sent from my iPhone
> On 22 Jul 2014, at 07:55, "Eli Stevens (Gmail)" <wickedg...@gmail.com> wrote: > > One quick thought: > > Clustered couchdb has been a while coming, and still has a while to go > before it's ready; I would suggest not saddling the release with > additional changes or requirements, especially if they're the type > that can be bikeshedded to death (stuff like API changes can take a > while to sort out). > > I'd much rather see CouchDB 4.0 sometime next year than have to wait > until next year for 2.0. > > Cheers, > Eli > > On Sat, Jul 19, 2014 at 5:23 AM, Robert Samuel Newson > <rnew...@apache.org> wrote: >> >> What important tools or browsers still need text/plain for our json >> responses that justify the mismatch? >> >> >>> On 19 Jul 2014, at 11:30, Jan Lehnardt <j...@apache.org> wrote: >>> >>> >>>> On 19 Jul 2014, at 12:27 , Robert Samuel Newson <rnew...@apache.org> wrote: >>>> >>>> I agree with you on the category split and, obviously, that we can make a >>>> 3.0 whenever we like, since it only indicates compatibility breaks. >>>> >>>> MVCC for _security will be great since it will enable us to heal _security >>>> writes during partitions with the same logic we use for documents. >>>> Cloudant worked around (hacked around) that problem for a long time but >>>> we’ve finally done the work to add MVCC for reals, so it’ll be nice to >>>> bring that enhancement to CouchDB officially. >>> >>> Yeah, I don’t see a reason not to get this in for 2.0. >>> >>> >>>> I don’t think defaulting to conflicts=true is quite the right change. I >>>> was thinking that conflicted document would return a 300 Multiple Choices >>>> instead of a 200 OK (the response body format TBD but imagine a JSON array >>>> of each conflicting leaf revision). I agree that a change like that will >>>> break every client, but that would be the intention. A CouchDB 3.0 would >>>> be much more forthcoming about its fundamental architecture and would >>>> largely eschew the attempts to present an arbitrary "winning" revision. >>> >>> Right, this was just meant as a possible compromise to get a more >>> first-class-conflict API without making this 3-rd category change. Happy to >>> abandon it :) >>> >>> >>>> One further thought occurs, could we totally ditch the code that returns >>>> "text/plain" content-type? All that "are you a browser?" logic? It made >>>> sense at the time, but I feel it confuses more than it helps today. >>> >>> I use that all the time :) >>> >>> Best >>> Jan >>> -- >>> >>> >>> >>>> >>>> B. >>>> >>>> >>>>> On 19 Jul 2014, at 10:50, Jan Lehnardt <j...@apache.org> wrote: >>>>> >>>>> >>>>>> On 19 Jul 2014, at 10:38 , Robert Samuel Newson <rnew...@apache.org> >>>>>> wrote: >>>>>> >>>>>> >>>>>> I think this is backward. We are not proposing API changes "just >>>>>> because" BigCouch happens to make them. >>>>>> >>>>>> Given that we have to bump the major version number, we are afforded an >>>>>> opportunity to improve our API in significant ways for the first time >>>>>> since 1.0. We all know there are warts to be fixed. The question is what >>>>>> to fix with 2.0, seeing as we’re making one. >>>>> >>>>> That is what I meant to express, with the caveat that we should be >>>>> careful, taking a conservative stance, so we can meet in the middle. >>>>> >>>>> >>>>>> I would also hate to see low adoption of CouchDB 2.0 if we change too >>>>>> much, because I’ve spent quite a bit of time trying to make it happen. >>>>>> >>>>>> Is there nothing, besides what comes with the BigCouch merge, that we >>>>>> wouldn’t want to change for 2.0? At least the ability to add metadata >>>>>> without breaking 2.0 compliant clients and libraries, I hope? >>>>> >>>>> >>>>> Most apps should continue to work on CouchDB 2.0. >>>>> >>>>> Specifically, the regular document CRUD cycle should work as-is. >>>>> Especially moving things around in the JSON usually goes further >>>>> than the HTTP/Couch layer of most apps, as it is usually passed >>>>> down into the rest of the app, while HTTP specifics are kept on >>>>> the outside. >>>>> >>>>> In that scenario, adding properties should be easier to do than >>>>> removing them (e.g. _conflicts could be standard, but renaming >>>>> _rev to _mvcc would break things more significantly), although >>>>> Bob mentioned the replicator compatibility as a major concern, >>>>> so we need to make sure this is doable. >>>>> >>>>> My main point here is to start a discussion about how we would >>>>> go about evolving this down the road and my suggestion was the >>>>> separate API endpoint that we can mess with at will and gradually >>>>> introduce until we switch at a later time when we feel confident >>>>> that people have migrated, or a solid compatibility API is available. >>>>> >>>>> I see us having three discussions: >>>>> >>>>> 1. What do we want to fix/break for 2.0? >>>>> 2. How do we introduce fixes/breaks that we aren’t comfortable doing for >>>>> 2.0? >>>>> 3. What do we want to fix/break for later versions? >>>>> >>>>> >>>>> From this thread, I’d handwavingly suggest these fall into category 1: >>>>> (as per the “most apps should just continue to work”-mantra): >>>>> >>>>> - timeout and heartbeat params for /_db_updates works in different way >>>>> then the same parameters for changes feed; >>>>> - we need to find the way to pass open_revs in POST body instead of >>>>> tweaking max URL param; >>>>> - we have /db/_revs_diff and /db/_revs_missing endpoints which are >>>>> doing the same job. Well, the latter is only used for pre-1.1 CouchDB >>>>> replicator. >>>>> - /db/doc accepts conflicts, deleted_conflicts and revs params. In the >>>>> same time we provides meta one which includes each of specified. >>>>> - make eventsource feed to follow the specification format more better >>>>> then it does now >>>>> - MVCC for /db/_security and allow atomic changes for admins/members only >>>>> - a variant of “Changing the default respones for conflicts to include all >>>>> versions (or no version).” where ?conflicts=BOOL defaults to true, so we >>>>> get an additional _conflicts: [] member on regular GETs (if there are >>>>> conflicts), but not the conflicting versions themselves (see above note >>>>> about additional doc members) >>>>> - Fix the list API (inside couchjs) so that its a pure callback like >>>>> everything else. >>>>> - 'JSONP responses should be sent with a "application/javascript"' >>>>> >>>>> >>>>> These fall into category 3: >>>>> >>>>> - Change _rev to _mvcc or other. >>>>> - Move document metadata elsewhere (sub-object, headers, whatever) >>>>> - Changing the default respones for conflicts to include all versions >>>>> (or no version). >>>>> - more RESTy API (move /_all_docs to /, db info to _info etc), >>>>> self-defining REST API >>>>> - don’t pollute top level namespace (e.g. /database moves to /db/database) >>>>> >>>>> This isn’t exhaustive, and we don’t yet know the answers to some of them. >>>>> >>>>> As a repeat: with our new understanding of SemVer, we are free to ship >>>>> CouchDB >>>>> 3.0 a month after 2.0, if we really want to. We are not beholden to >>>>> marketing >>>>> version numbers after 2.0 (strictly, we aren’t for 2.0 either, but it is >>>>> rather convenient :). >>>>> >>>>> * * * >>>>> >>>>> The view server protocol change suggested by Samuel is IMHO an internal >>>>> change that should not break BC unless people rely on implementation >>>>> details. >>>>> >>>>> >>>>> * * * >>>>> >>>>> Most apps should continue to work on CouchDB 2.0. >>>>> >>>>> Jan >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Adding a new top-level _-prefixed field in couchdb causes the replicator >>>>>> to crash hard, this is unacceptable brittle imo. >>>>> >>>>>> >>>>>> B. >>>>>> >>>>>>> On 18 Jul 2014, at 21:15, Jan Lehnardt <j...@apache.org> wrote: >>>>>>> >>>>>>> I’m major -1 on substantial API changes *just* because we are having >>>>>>> some >>>>>>> by necessity of getting BigCouch in. >>>>>>> >>>>>>> The minor improvements mentioned previously in this thread sound >>>>>>> reasonable, >>>>>>> but changing the main JSON format seems like a rather bad idea as it >>>>>>> will >>>>>>> just break all clients. While the scenario is a little different, I’d >>>>>>> like to >>>>>>> avoid a Python 3 kind of situation (I think CouchDB 2.0 has more to >>>>>>> offer over >>>>>>> 1.0 than Python 3 had over 2, but still, there is no need to make this >>>>>>> harder >>>>>>> for our users, if we don’t have to). >>>>>>> >>>>>>> That said, we likely want to evolve the API at some point and I think >>>>>>> we should >>>>>>> nail down a strategy on *how* to do that, before getting into the >>>>>>> details of >>>>>>> what should change. >>>>>>> >>>>>>> One option, and I haven’t thought this through, would be to use >>>>>>> separate ports >>>>>>> for a new API endpoint that we can evolve while keeping the current >>>>>>> one. And >>>>>>> we can do the deprecation and switch dance some time in the future. We >>>>>>> could >>>>>>> even try multiple competing APIs, even non HTTP APIs (all things, I’d >>>>>>> love to >>>>>>> see, so we can learn from them). Of course there is a certain overhead >>>>>>> in >>>>>>> maintaining this all, and I don’t know if there are any roadblocks in >>>>>>> the way >>>>>>> BigCouch works today for implementing this. >>>>>>> >>>>>>> Best >>>>>>> Jan >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 17 Jul 2014, at 21:03 , Russell Branca <chewbra...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I would also love to see _rev renamed, and I think it's a good >>>>>>>> opportunity to flip around all the meta info as well. I'm still >>>>>>>> partial to moving the relevant metadata into the headers, and no >>>>>>>> longer including any _* fields in the doc, but I know there are >>>>>>>> proponents on both sides of the coin there. The most recent proposal I >>>>>>>> could find is to move all the metadata into a '_' field [1]. In 2.0 I >>>>>>>> would like to see us move all metadata into headers or into the '_' >>>>>>>> field, and rename 'rev'. There's a lot of code overlap for the two so >>>>>>>> it seems like an opportune time to do it. >>>>>>>> >>>>>>>> I wonder if it's reasonable to make the use of a '_' field or exposed >>>>>>>> through headers configurable. I'm not sure it's a great idea to do so, >>>>>>>> but it's at least worth thinking about. >>>>>>>> >>>>>>>> Exposing conflicts by default is another thing I'm keen on. The >>>>>>>> question is how to make it "fail" loudly so that client libraries >>>>>>>> don't just think it's the document body. An aggressive approach send a >>>>>>>> list of conflict revs rather than a doc object which will break all >>>>>>>> existing parsers and require users to deal with. Then if you want a >>>>>>>> particular rev, you'll need to specify it in the request. >>>>>>>> >>>>>>>> We could also cleanup the API endpoints to make them more RESTful. IMO >>>>>>>> things like _all_dbs and _all_docs should be the top level endpoints >>>>>>>> and the current info endpoints moved to _info or some such. >>>>>>>> >>>>>>>> Along the lines of API cleanup is the capabilities engine. I think >>>>>>>> this would be a great thing to land, and if done properly could be a >>>>>>>> self defining REST endpoint showing all the things the server is >>>>>>>> capable of and how to reach them. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -Russell >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://mail-archives.apache.org/mod_mbox/couchdb-dev/201312.mbox/%3c529de44c.4090...@bigbluehat.com%3E >>>>>>>> >>>>>>>> On Thu, Jul 17, 2014 at 2:14 AM, Robert Samuel Newson >>>>>>>> <rnew...@apache.org> wrote: >>>>>>>>> Great point, +1 to just making that change on master right now. >>>>>>>>> >>>>>>>>> B. >>>>>>>>> >>>>>>>>>> On 16 Jul 2014, at 22:35, Robert Kowalski <r...@kowalski.gd> wrote: >>>>>>>>>> >>>>>>>>>> I would like to see 'JSONP responses should be sent with a >>>>>>>>>> "application/javascript"' >>>>>>>>>> (https://github.com/apache/couchdb/pull/236) >>>>>>>>>> beside the two merges in the 2.0 release - it is a small, but >>>>>>>>>> breaking >>>>>>>>>> change and the original issue is flying around in Jira for years. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2014-07-13 22:17 GMT+02:00 Robert Samuel Newson <rnew...@apache.org>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Since we follow semantic versioning, the only meaning behind naming >>>>>>>>>>> our >>>>>>>>>>> next release 2.0 and not 1.7 is that it contains backwards >>>>>>>>>>> incompatible >>>>>>>>>>> changes. >>>>>>>>>>> >>>>>>>>>>> It’s for the CouchDB community as a whole to determine what is and >>>>>>>>>>> isn’t >>>>>>>>>>> in a release. Certainly merging in bigcouch and rcouch are a huge >>>>>>>>>>> part of >>>>>>>>>>> the 2.0 release, but they aren’t necessarily the only things. If >>>>>>>>>>> they >>>>>>>>>>> hadn’t changed the API in incompatible ways, they wouldn’t cause a >>>>>>>>>>> major >>>>>>>>>>> version bump. >>>>>>>>>>> >>>>>>>>>>> With that said then, I’m interested in hearing what else, besides >>>>>>>>>>> the two >>>>>>>>>>> merges, we feel we want to take on in our first major revision bump >>>>>>>>>>> in >>>>>>>>>>> approximately forever? At minimum, I would like to see a change >>>>>>>>>>> that allows >>>>>>>>>>> us to use versions of spidermonkey released after 1.8.5, whatever >>>>>>>>>>> that >>>>>>>>>>> change might be. >>>>>>>>>>> >>>>>>>>>>> B. >>>>>>>>>>> >>>>>>>>>>>> On 13 Jul 2014, at 20:31, Joan Touzet <woh...@apache.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Improving the view server protocol is a great idea, but it is >>>>>>>>>>>> appropriate >>>>>>>>>>>> for a 2.0 timeframe? I would think it would make more sense in a >>>>>>>>>>>> 3.0 >>>>>>>>>>>> timeframe, given 2.0 is all about merging forks, not writing new >>>>>>>>>>>> features >>>>>>>>>>>> entirely from scratch. >>>>>>>>>>>> >>>>>>>>>>>> -Joan >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Robert Samuel Newson" <rnew...@apache.org> >>>>>>>>>>>> To: dev@couchdb.apache.org >>>>>>>>>>>> Sent: Sunday, July 13, 2014 8:52:40 AM >>>>>>>>>>>> Subject: Re: CouchDB 2.0: breaking the backward compatibility >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Adding mvcc for _security is a great idea (happily, Cloudant have >>>>>>>>>>>> done >>>>>>>>>>> so very recently, so I will be pulling that work over soon). >>>>>>>>>>>> >>>>>>>>>>>> A better view server protocol is also a great idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 13 Jul 2014, at 13:13, Samuel Williams < >>>>>>>>>>>> space.ship.travel...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 13/07/14 23:47, Alexander Shorin wrote: >>>>>>>>>>>>>> Our view server is compiles functions on each view index update >>>>>>>>>>>>>> instead of reusing inner cache. This is because of out-dated >>>>>>>>>>>>>> protocol: >>>>>>>>>>>>>> others design function are works differently from views. While >>>>>>>>>>>>>> it's >>>>>>>>>>>>>> good to change and improve query server protocol completely, >>>>>>>>>>>>>> this task >>>>>>>>>>>>>> requires more time to be done. We should have a least plan B to >>>>>>>>>>>>>> do >>>>>>>>>>>>>> small steps in good direction. >>>>>>>>>>>>> As already suggested, here is my proposal for 2.0 view/query >>>>>>>>>>>>> server: >>>>>>>>>>> https://docs.google.com/document/d/1JtfvCpNB9pRQyLhS5KkkEdJ-ghSCv89xnw5HDMTCsp8/edit >>>>>>>>>>>>> >>>>>>>>>>>>> I welcome people to suggest improvements/changes/ideas. >>>>>>>>>>>>> >>>>>>>>>>>>> Kind regards, >>>>>>>>>>>>> Samuel >>
