RFC : Port cohttp-lwt-unix to eio using lwt_eio #854
RFC : Port cohttp-lwt-unix to eio using lwt_eio #854bikallem wants to merge 4 commits intomirage:masterfrom
Conversation
disable jsoo packages
Convert Cohttp_lwt.Client and Cohttp_lwt.Net modules to direct style API.
|
Wow, thanks a lot. I will need a few day to look at it and play with it. From my point of view is great to have this, but will require some extra thinking. For example, from the top of my head, this would make it only available on ocaml 5.0+, right? |
Correct. Also mirage and jsoo packages will be unavailable since jsoo and mirage don't yet support ocaml 5.0 effects. |
|
Thanks for this @bikallem! As a counterpoint, do you also have the WIP port of cohttp directly to eio? (without Lwt_eio). That would perhaps give us a feel for what a totally separate implementation of cohttp without Lwt looks like. |
|
If needed, I have a fork of cohttp and conduit lying around using only unix (mostly worked but was single threaded still, I have never found the time to fix it) |
Sure, I will create another PR with pure eio cohttp as a counter point. |
|
Am I the only one who is curious about how eio performs under cohttp as well? |
|
No. I can’t wait to test it! |
|
I have opened a draft PR for eio-only cohttp - #857 |
Thanks. To proceed with this PR, I think we need a separate |
|
Let's focus on getting #857 in first. This adapter will be easier to figure out once we have the pure eio version in |
|
closing this since #857 adds cohttp-eio |
This is a WIP port of
cohttp-lwt-unixto eio using thelwt_eio(https://github.com/talex5/lwt_eio/) library.lwt_eiois aneiobackend forlwtand allows existing lwt libraries to used together witheio.Asides:
cohttp-lwt-unixand it is not backwards-compatible with existing codebases. Should this live off new package altogether?The gist of the PR is the new
Cohttp_lwt_unix.ClientandCohttp_lwt_unix.ServerAPI which doesn't expose any'a Lwt.tin the module interface signature. This allows a direct style of coding where thelwtmonad and its artefacts(>>=,>|=, bind, map etc) are less pronounced, visible or necessary.The purpose of this Draft PR is to get a feeler for what the maintainers think of this PR? Is there an appetite for this work?