Hi Vasilij, Thanks so much for the reply!
> > - This implementation passes all of the Autobahn compliance tests. > > I've included the client and configuration file in an examples/ > > directory, but the repository currently has no tests/ because the > > Autobahn tests are usually run from a docker image and take a while to > > finish. > > I don't know much about websockets at all, but would it be possible to > at least include a smoke test or sanity check? There are a few eggs > (json-rpc, srfi-18, fuse, gochan, sendfile, spiffy) that spawn a server > process with process-fork, send a request to it and check whether it was > successful. There's even the server-test egg dedicated for this purpose. A sanity check at least would certainly be a good thing to have. I think it might have to be somewhat ad-hoc because I don't have a server implementation yet, but I'll try to put something together. Thanks for the pointers! > > - permessage-deflate presently interfaces with the C zlib directly, > > because we use options for the stream interface that the zlib egg > > doesn't currently expose. This results in some repeated code. > > I've hacked on that egg recently and discovered that the author wanted > to expose deflateInit2 and inflateInit2 for a while, so I helped review > their code and they released a new version exposing MAX_WBITS. I've also > submitted a PR demonstrating how this can be used to handle raw deflate, > zlib and gzip data: <https://github.com/r1b/zlib/pull/2>. Perhaps this > is of use. The thing I was specifically using was specifying Z_FULL_FLUSH when the no_context_takeover parameter is set. I suppose I could instead reset the state by opening a new stream with every message, but that feels very unsatisfying. To use the zlib egg's interface for permessage-deflate will require a pretty substantial refactor, and since the only thing the library really needs to do is deflate/inflate a whole string in one go, passing through CHICKEN's input/output-ports and back seems like overkill anyway, actually. Maybe I am okay with that part of the code staying the way it is. > The code looks fine to me. There's small improvements that can be made > to improve readability: Thanks for the style check! In any case, thanks again for the very informative response! I'm certainly writing all of these things down for when I put together a next release, hopefully soon. Ka-tsùn
