Am 16.02.2018 um 01:38 schrieb gallafrancesco:

FraMecca and I are two students from University of Turin, Italy. We would like to have HTTP/2 support built inside vibe.d and contribute to it, even if it means working on a design of the whole HTTP module.

Nowadays, there is also the plan to redesign the HTTP module in general
to remove performance bottlenecks, especially those that ironically
surfaced with the new vibe-core module, which is actually designed to
improve performance.

For these reasons it is unlikely at this point that the branch will ever
be merged. Instead, the redesigned HTTP module will be built for HTTP/2
from the ground up. For now I have added some very basic design
considerations: https://github.com/vibe-d/vibe-http/wiki

We would like to know if it is actually possible to start working on this, and if so, if you or someone else is already on it.

Could you give us a more detailed explanation of your design from the vibe wiki?

On Wed, 14 Feb 2018 10:08:22 +0100, Sönke Ludwig wrote:

Am 14.02.2018 um 00:08 schrieb FraMecca:

Reading about the http2 support for vibe proposed on GSoC 2018 I was wondering what is the status of the http2-botan branch on the official vibe.d repo and if it is abandoned.

Supposing a group of person needs to tackle the problem of http2 support, could they start from there?

The http2-botan-cleanup branch is the one that is closest to being ready
to merge into master. However, it generally suffers from two major
issues. Firstly, it simply performs a huge amount of changes, including
refactoring and API changes, in a single step, which makes it de-facto
impossible to review, and then it also contains code from another
library, with a different license, which I'd really like to avoid.

Nowadays, there is also the plan to redesign the HTTP module in general
to remove performance bottlenecks, especially those that ironically
surfaced with the new vibe-core module, which is actually designed to
improve performance.

For these reasons it is unlikely at this point that the branch will ever
be merged. Instead, the redesigned HTTP module will be built for HTTP/2
from the ground up. For now I have added some very basic design
considerations: https://github.com/vibe-d/vibe-http/wiki

So basically so far there is just the design constraints from the wiki
and the existing API as a guide for the new design. The new high level
API should be as compatible as possible to the old one, from the typical
library user's point of view, while the a low-level API can be freely
redesigned for minimal overhead.

There could also be an alternative high-level API, such as something in
the direction of the HTTPInterchange draft in the wiki, but I'd see
that as something that only makes sense if the existing approach shows
severe weaknesses in a certain area. Otherwise that would be a topic for
a 2.0 version.

How all of this translates into a concrete design is yet to be
determined and would be part of the process. Unfortunately my priorities
are currently (for the next few months) forced to be more or less
focused only on our internal project, so that I have very little time
left to invest into this. Depending on your time constraints I could try
to squeeze out a little dedicated time per week, though, because this
really is something that I'd like to see materialize sooner rather than
later.

I could also try to commit a very basic code skeleton that accepts
connections, including the TLS based HTTP version negotiation, so that
there is something to start from.