couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: CouchDB 2.0: breaking the backward compatibility
Date Fri, 18 Jul 2014 20:15:37 GMT
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 <chewbranca@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.4090400@bigbluehat.com%3E
> 
> On Thu, Jul 17, 2014 at 2:14 AM, Robert Samuel Newson
> <rnewson@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 <rok@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 <rnewson@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 <wohali@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" <rnewson@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.traveller@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
>>>>> 
>>>> 
>>>> 
>> 


Mime
View raw message