I'm curious what the status and merge plan of this PR is. It could as well be part of a separate git repository if the httpaf maintainers do not want to maintain the mirage adapter. what do you think?

Haven't had time to look at this too closely, as I'm prioritizing bug fixes at the moment. However, this like the lwt runtime, is a copy paste job. Eventually, having a bunch of different copies of the same code is going to become a nightmare to maintain and isn't going to make it easy to share fixes.

Async's different enough that the split there is justified. But for the lwt-based runtimes, if possible, the implementations should just be functorized, or otherwise parameterized.

I'm at the Mirage retreat this week and I can have a look into finding an abstraction to share code between the Lwt and Mirage runtimes.

Looks good!

Summary of recent changes:

• httpaf-lwt now provides functors that can be used to construct Lwt-based http/af runtimes
• httpaf-lwt-unix provides a package that implements the UNIX runtime (what httpaf-lwt was before)
  • the name change is fine IMO because httpaf-lwt was never released to OPAM
• httpaf-mirage implements a Mirage runtime based on Conduit_mirage

Most of the Lwt runtime code can now be shared, and there's only one implementation of the I/O loops.

I will look tomorrow about this PR, the question between compatibility between mirage (mostly conduit), others stuffs (like async) and httpaf is not so easy. I completely understand your concerns but I think, in some ways, some tasks will not be done ...

But thanks for your fast as f**k replies 👍 ! Today is Sunday!

@seliopou Thanks for your review and suggestions. I just implemented them in e6c90cf and 793da4a (separate commits should hopefully make the next round of review easier).

The unix-independent Lwt part of this would be very useful to have in httpaf, but I recommend putting the Mirage piece of this PR into a separate repository under the mirage/ org and not to include it in the httpaf repository.

We'll likely need to iterate on the example unikernel and interfaces from the Mirage end more quickly as we head towards a Mirage4 release, but the httpaf-lwt portion is unlikely to need too many changes.

Hmmhmm, with your last commit, I did not know exactly where it comes but it's not so easy to make an HTTP server:

let start console clock conduit http =
  let server = Httpaf_mirage.Server_with_conduit.create_connection_handler
    ~request_handler
    ~error_handler
    ~config:Httpaf.Config.default in
  http (`TCP 4242) server

if I remove the optional ?config argument, the error is not so clear to be understandable. I don't know the best way to fix it but even if you write:

val create_connection_handler : request_handler:_ -> error_handler:_ -> ?config:Config.t -> (flow -> unit Lwt.t)

OCaml consider it as:

val create_connection_handler : request_handler:_ -> error_handler:_ -> ?config:Config.t -> flow -> unit Lwt.t

And ?config still is a non-applied argument.