Re: Egg: ws-client

[Ka-tsùn Lo̍h]

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