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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >
