What QPACK implementation should we use?

[jlaine]

The initial choices which come to mind:

• wrap an existing C implementation of QPACK, as I've attempted in https://github.com/aiortc/pylsqpack/

• write a pure Python implementation, which would be more debugable but probably more work

[tomchristie]

Generally with these sorts of things I'd take an MVP approach.

If you can get an initial version working more quickly with the pylsqpack then I'd start by rolling with that. (And live with the additional constraints that entails.) If you make sure there's a clear interface onto it, then you can make switching out to an alternative pure-python implementation at a later date fairly easy. (Or even better end up making it configurable.)

Uvicorn took a similar approach, initially starting with httptools as its only HTTP parser implementation, and later adding a pure Python h11 implementation. That hit the sweet spot of what most people wanted it for first. Ending up with two alternate implementations onto the same interface is also golddust for being able to isolate issues further down the road, as you can easily determine if both have the same behavior wrt. a bug report or not.

If there's a clearly defined interface you've also taken yourself off the critcial path wrt. implementing a pure python version. You've got something you can start working with and testing, and if someone else wants to take on the pure python implementation, then they've already got nicely defined boundaries to work against.

[sethmlarson]

(Currently working on such a Python implementation, quic-qpack)

My reasoning behind why you almost certainly wouldn't want a QPACK library written in Python is the same reason why you wouldn't want a Brotli library written in Python: It's all data serialization and C will pretty handily win in performance. I'll continue working on it though, will be useful to have a library to compare outputs against.

[jlaine]

@sethmlarson I'm really interested in seeing what approach you're taking regarding "blocked streams", so far I have not come up with an API I like to wrap lsqpack's. It exposes two methods into the decoder:

• lsqpack_dec_header_in which actually feeds data into the decoder, but can return LQRHS_BLOCKED if decoding is blocked

https://github.com/litespeedtech/ls-qpack/blob/02c4e282c403f5b9f69344a1c812d617fdd53e1a/lsqpack.h#L319

• lsqpack_dec_header_read which doesn't feed any extra data but which you can call once you have been notified that the stream in unblocked

The "notification" takes the form of a callback which you specify when initializing the decoder:

https://github.com/litespeedtech/ls-qpack/blob/02c4e282c403f5b9f69344a1c812d617fdd53e1a/lsqpack.h#L271

So far I just plain bomb if lsqpack_dec_header_in returns anything other than a success..

https://github.com/aiortc/pylsqpack/blob/ba858742d800be5867a8df3b5c1309a8a49c4441/src/module.c#L69

[jlaine]

I'm going to close this issue, pylsqpack seems OK for now