Status of the project?

[Lupus]

Changelog looks pretty impressive, but so far is unreleased. Are there any plans to release this fork under different name on opam? Also, what are the future plans for this project?

We're currently using upstream httpaf, with custom Lwt adapter that adds SSL and were thinking about client-side keepalive, but looks like many of features we're thinking of are implemented here. So I wanted to clarify the project status to get a general feeling of where it's going. Thanks in advance!

[anmonteiro]

Hey @Lupus,

thanks for taking an interest in this project. Let me try to break down some of your questions:

Are there any plans to release this fork under different name on opam?

I'm a little torn on this, mostly because I don't wanna steal anyone's thunder. So I've been quietly using this myself and recommending to a few others via opam pins / esy resolutions. I realize If there's interest from more folks then I'll indeed have to release the project 🙂I would encourage you to try it out this way, and I'd love to hear any feedback!

Also, what are the future plans for this project?

I've been using it myself in various things (mostly on the client side, but it's also been tested in server scenarios), and I know a few others who have been doing the same. So far so good.

I really like how http/af is architected so I'm planning on maintaining this for the time being. Ideally some or all of my improvements would make it upstream, but unfortunately I don't think that's realistic (there's more context scattered around on this, but https://github.com/inhabitedtype/httpaf/issues/82 is probably a good start to understanding my reasoning for the above).

were thinking about client-side keepalive

This is one of the reasons why this fork exists too. I saw a 20-25% speedup over at aws-lambda-ocaml-runtime (https://github.com/anmonteiro/aws-lambda-ocaml-runtime/pull/33) when I switched the client to keep a connection alive. More to come on this soon too!

[Lupus]

I'm a little torn on this, mostly because I don't wanna steal anyone's thunder.

As long as original copyright is retained, and licensing terms are met, I don't think that it will be considered as stealing. Explicitly stating it's a fork and mentioning original authors somewhere in the top of README/documentation usually makes everyone happy.

I would encourage you to try it out this way, and I'd love to hear any feedback!

Yeah, for trying out I'll use an opam pin, but those are not transitive and at some point we'll want to publish forked version to our internal repo under a different name anyways :) Well, if it works well in our project which can be figured out only by trying :-p

I really like how http/af is architected so I'm planning on maintaining this for the time being. Ideally some or all of my improvements would make it upstream, but unfortunately I don't think that's realistic

I've got an impression that upstream has very little time for maintaining httpaf. If you have more time for this project, you'll get fore features delivered/bugs fixed and attract more audience.

ReasonML as a modern language (tsss, don't tell anyone it's OCaml in disguise) needs proper HTTP stack to be successful in the backend field.

[anmonteiro]

I'm a little torn on this, mostly because I don't wanna steal anyone's thunder.

As long as original copyright is retained, and licensing terms are met, I don't think that it will be considered as stealing.

I didn't mean "steal" work. I know that we can publish derivative work. "stealing someone's thunder" is an expression that means shifting attention away from the original project in this case.

Yeah, for trying out I'll use an opam pin, but those are not transitive

I made sure to add pin-depends, so you should get the transitive deps if you request a pin to httpaf-lwt-unix: https://github.com/anmonteiro/httpaf/blob/90e7c8783a99bdb9f098b017a2ca34516de0abad/httpaf-lwt-unix.opam#L24-L27

[Lupus]

I'm a little torn on this, mostly because I don't wanna steal anyone's thunder.

As long as original copyright is retained, and licensing terms are met, I don't think that it will be considered as stealing.

I didn't mean "steal" work. I know that we can publish derivative work. "stealing someone's thunder" is an expression that means shifting attention away from the original project in this case.

Sorry, I poorly formulated my though. What I was trying to say is that credit for original work should bring more attention to the upstream as well, and thus you will not be stealing that attention (at least completely). Hope it makes more sense now.

I made sure to add pin-depends, so you should get the transitive deps if you request a pin to httpaf-lwt-unix:

See this comment (and the rest of the discussion): https://github.com/ocaml/opam/issues/4003#issuecomment-539528783

pin-depends do not work transitively enough at least for my use case :) We have some big library, which wraps up httpaf and a bunch of other dependencies, adds some goodies on top, and is then used in services, and if something is pinned in the library, it won't appear in the service.

Nevermind, we maintain an internal repo exactly to address this issue and can publish forked version of httpaf there if it works well.

We'll definitely consider trying this project when time allows. Thanks for explaining your vision!

[v0idpwn]

Maybe this could be released under another name on opam while keeping the fork status in the repository? This would solve https://github.com/anmonteiro/piaf/issues/90 and other compatibility issues without "stealing their thunder" :)

[anmonteiro]

Changing the name of the modules would make it impossible for h2 to work with both upstream and this version. That's not something I'm considering at the moment.

[chris-armstrong]

I'm wondering if there has been any thought about this over the past 3 years? inhabitedtype/httpaf still seems unmaintained and the patches here related to eio are quite useful - I'd love to get this into opam.

[anmonteiro]

I'm planning on releasing it soon. Here are the proposed steps:

• [x] detach the fork from the original repository
• [x] rename the project to httpun -- this is both "HTTP One" (un is one in french) and a pun on HTTP
• [x] release to OPAM

[chris-armstrong]

That's awesome - let me know if there are auxilliary tasks I can help with (documentation, nursing PRs, etc)

[anmonteiro]

submitted to opam https://github.com/ocaml/opam-repository/pull/26042

[anmonteiro]

httpun is now available on OPAM.

[chris-armstrong]

Thanks @anmonteiro! Glad to see this is available now