@janl:
- cowboy
- needs fabric / couch_httpd refactor
- would obviate the need for WebSockets
I think this is an obvious first next step. Our HTTP Layer needs work, our existing HTTP server library is not getting HTTP2 support, it’s time to attack this head-first. I’m imagining a Cowboy-based HTTP layer that calls into a unified internals layer and everything will be rose-golden. HTTP2 support for Cowboy is still in progress. Maybe we can help them along, or we focus on the internals refactor first and drop Cowboy in later (not sure how feasible this approach is, but we’ll figure this out.In my head, we focus on this and call the result 3.0 in 6-12 months. That doesn’t mean we only do this, but this will be the focus (more on this later).
There are a few fun considerations, mainly of the “avoid Python 2/3-chasm”-type.
- Do we re-implement the 2.0 API with all its idiosyncrasies, or do we take the opportunity to clean things up while we are at it?
- If yes, how and how long do we support the then old API?
- Do we manage this via different ports?
- If yes, how can this me made to work for hosting services like Cloudant? Etc. etc.
For the HTTP API upgrades, we should look at this as a step in refactoring the logic quite a bit and working for clean interfaces internally. If we include that as part of the work then having HTTP/HTTP2/WebSockets/Whatevers interfaces available would become much easier. This then enables follow on features like replication over WebSockets or even easier integration work as Koco suggests. I also agree that this is probably our highest priority major feature.
since all this went down, we kinda sorta decided we don’t want to go down the cowboy route. Alternatives are TBD.
Since haproxy has H2 support now, and since it is useful to run it even in front of a single instance CouchDB, we have some time to get to this.
This then enables follow on features like replication over WebSockets
Huge +1 for support of replication through WebSockets since it saves a _lot_ of overheads. Also would be awesome to be able to use WebSockets to connect to CouchDB at some point.
EDIT: from what I understood, WebSockets over SSL (WSS) create a secure channel between the client and the server, which avoids the need for authenticating for each request.
IBM Cloudant supports HTTP/2 : "HTTP2 support for higher performance connections to IBM Cloudant" (https://github.com/IBM/cloudant-java-sdk)
@yhilem Yup, and they also use a proxy in front of CouchDB. This is recommended standard practice. Terminate your HTTP/2 (or QUIC!) SSL connection at e.g. haproxy, then haproxy forwards it on to CouchDB.
@wohali please tell me when you want to implement http2 in CouchDB. I watched that you see is created on 2018. Please tell me when you you want to implement it on CouchDB.
I'm just a project management committee member here, not an implementer on this type of feature.
Implementing this is a lot of work. Pull requests are welcome!
I think Jan's original notes are still spot-on a few years later, with "Cowboy" as a proxy for "some modern Erlang / Elixir HTTP server" and "2.0 / 3.0" replaced with "3.0 / 4.0".
If we decide to move forward on the versioned API topic currently under discussion on the ML I would advocate for the 4.0 API to pull in a new HTTP server that would deliver HTTP2 support amongst other goodies.