On Sun, 18 Feb 2018 10:46:44 GMT, gallafrancesco wrote:

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.

Can you give us the code skeleton for reference?
We are eager to try and to take on the challenge to rewrite the api given your guidelines.
At this point we can analyze your code and come up with a draft of the new API for a further discussion.

It's not written yet and I'm currently having trouble allocating the time for it, but if you want to start now, I'd just recommend to maybe take the basic listenHTTP code (plus HTTPListener etc.) and start to implement the low level API from there (pulling bits out of the old code as necessary).

I would try my best to offer timely feedback (maybe we can open a channel on the dlang Slack for that, or I could create a separate forum). But you should be willing to potentially reshape the API during the process, as I'm sure that part of the design process will only become clear after the first code has been written.

But I'll commit at least the package skeleton later today, so that the repository can be used for development.

Regarding your wiki, there's a point which states:

no stream proxy objects or dynamic dispatch by default - all combinations of
encryption/encoding/compression streams must be instantiated as static types

  • need to keep in mind how to minimize the amount of template bloat this produces

Do you have any example of this in the current vibe implementation?

InterfaceProxy is the main offender in that regard. It currently still needs to be used in a few places in the HTTP module, because the code previously relied on streams being class objects and thus supporting efficient dynamic dispatch by nature. Since the new streams from vibe-core are usually structs now, this rather ineffcient workaround is needed.

The goal would be to only store concrete (template instance) types, or at least to not perform any dynamic dispatch in potential hot code paths.

However, there is at least one place where this will still be necessary in the high level API, HTTPServerResponse.bodyWriter. Instead of InterfaceProxy, I'd use asInterface there to avoid its additional wrapper layer.