Scope of this library, stdlib integration

[CrowdHailer]

Stdlib inclusion

@lpil mentioned that I should use this library so that I was using a standard HTTP method type.
Probably the only way I would find this type was if it was in standard lib. It's so small I am very likely to just re-implement. Also if there is something that it is expected everyone should use then is that not an argument for inclusion in stdlib?

What shouldn't this library do?

This question I think should be fairly similar regardless of if it will be included in stdlib or not, an http library on the gleam-lang repo will become the defacto standard

I am currently working on a Request and Response Type in midas, and the set of associated utilities e.g http.get_header, http.set_header etc. Would you be interested in a PR to add these to this project?

[lpil]

The problem with reimplementing it is that you would not be compatible with other HTTP using libraries as types in Gleam are nominal rather than structural. There would be a lot of added boilerplate.

I'm not yet sure if this library should be merged into the stdlib, more thought is needed.

RE Request and Response: we could implement these two types in many different ways so I'm not sure these are as suitable for being shared. If we do come up with an overarching abstraction I would like to consider how it works for HTTP 1, 2, and 3, how SSE works, and how middleware + error handling works. Without answers for so these I don't think we have an abstraction to share yet

[CrowdHailer]

I like where this has gone, is there anything I can help with for a new hex release. Midas is currently on my old shared message type, but I can't use this in a package I publish to hex yet.

[lpil]

Let's cut a release and see how it goes. Thanks for the nudge!

[lpil]

https://hex.pm/packages/gleam_http/1.1.0