ocaml-cohttp

ocaml-cohttp copied to clipboard

Love the idea of the new upcoming http package. It has types that we could share across HTTP implementations in the OCaml ecosystem.

How feasible would it be to pull the parser parts out of this package though, and have it contain mostly types?

What would be the advantage? The parser is not part of the public interface and requires no additional dependencies. The only gain would be to shave off the size of binaries by a little bit. Is that worth it?

The only gain would be to shave off the size of binaries by a little bit. Is that worth it?

That was the rationale behind my suggestion.

Alright, feel free to send a PR that moves the parser into a separate library (within the same package) if you really need this.

I don't "really need this". I think the benefit here would be the ability to share those type representations across the ecosystem. If this is not as welcome as I anticipated, I'm OK sticking with the status quo.

I think the benefit here would be the ability to share those type representations across the ecosystem

Is this benefit not already realized?

If this is not as welcome as I anticipated, I'm OK sticking with the status quo.

It's not that it's not welcome, it's just a bit too much of a niche feature for me to invest time in.

Is this benefit not already realized?

I'd imagine an HTTP library that's going to implement its own parser not to need to bring in another one.

it's just a bit too much of a niche feature for me to invest time in.

This makes sense. I'll see if I can spend some of my own time on this soon.

Sure there's a bit of redundancy but I claim that it's mostly harmless. OCaml binaries aren't very nimble after all.

By the way, give our http parser a try. It's hand written and is faster than httpaf's.

With cohttp-eio, http is almost enough ... except for Cohttp.Path.resolve_local_file. It would be nice if Http had this.

A solution would be to move that function (of the Path module) to Uri ?