llhttp should be a separate, optional package

[ml31415]

Is your feature request related to a problem?

Currently there are several projects having python bindings for llhttp. There is

• https://github.com/pallas/pyllhttp
• https://github.com/geventhttpclient/geventhttpclient
• aiohttp

And I probably missed a couple of other ones. pyllhttp hasn't been updated for a long time and geventhttpclient also struggles with maintenance. Having a single, well maintained bindings package would profit the python ecosystem and share the maintenance in more hands.

At the same time, there are requests from people using alternative python implementations asking for pure python packages for easier integration:

• Please upload a pure python wheel to PyPi #7632
• Aiohttp implementation for MicroPython #6584
• cannot install from source #7802

Separating llhttp into a separate package would make their life easier as well.

Describe the solution you'd like

aiohttp features the best maintained python bindings for llhttp. It would be great, if not only aiohttp could profit from them. Separating the llhttp bindings into their own package and having it available as a readily available HTTP building block in line with other packages like multidict, h11 etc. would profit the python HTTP eco system as a whole and also make life easier for aiohttp users of non-standard python implementations.

Describe alternatives you've considered

pyllhttp and geventhttpclient have their own bindings using a plain C extension. Though, the cython code of aiohttp is imho nicer to read for the python user and less error prone than the c code within geventhttpclient. As all bindings just wrap around llhttp, I guess the performance differences should be marginal.

Additional context

This is more like suggesting a restructuring and not a new feature. So I'm not that sure if it really belongs here or better into the discussion section. Please just move it there, if you think it fits better.

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[webknjaz]

I brought this up in the past, back when we were using the older project — http-parser — and not llhttp. I had similar thoughts but the reality is that the maintenance is not scalable.
I don't know who would have capacity to maintain a yet another thing. It took me over a year to just get to looking into multidict and releasing it, even more with Cheroot. More projects means more delays and more fragmented maintenance burden.

So while the idea is good (and I'd love to have an h11-compatible interface there), I personally am not ready to become responsible for an extra project being added to an already long list.

If somebody else is up for it, that's something to explore. But this would also open up a discussion of supply chain security. Not to mention potentially having to run a bigger CI matrix to account for compatibility with a bigger range of the critical dependency versions.

[ml31415]

Yeah, that are valid points. And of course it's nothing urgent. Maybe something to keep in mind and get a collaborative effort started at some point. Maybe also @pallas wants to revive his project at some point?