Repository navigation
Conversation
Codecov Report
@@ Coverage Diff @@
## master #676 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 29 43 +14
Lines 4388 4928 +540
Branches 406 436 +30
==========================================
+ Hits 4388 4928 +540
Continue to review full report at Codecov.
|
|
I just finished reading your blog post about this effort. That's a superb writeup! Thanks! One question I had when reading it: have you thought about whether there's an incremental way to start incorporating Sans I/O elements into your existing (non-Sans I/O) implementation? I'm wondering if it could help address some of the difficulties inherent in a "big bang" switch (as well as the need to maintain a parallel branch of such magnitude). |
|
Well it's pretty hard to avoid a big bang:
|
|
Just to clarify, I wasn't asking about the possibility of eliminating a big bang entirely, but rather decreasing the magnitude of the change by incrementally incorporating and using some elements of the Sans I/O implementation prior to completely switching over. For example, could parts of the implementation be used under the hood without affecting the public-facing API too much? As another example, could the HTTP aspects being added first, prior to the websocket aspects? |
|
In the PR, there's a lot of "moving + changing await to yield from + refactoring tests" which results in large changes that aren't really new code. It's quite hard to perform "socket transplantation" i.e. switching a network socket connected to asyncio utilities over to a sans I/O stack, or vice versa. Technically it must be possible (transfer the buffer over if needed) but it's far from trivial. |
89acad2 to
2cb836a
Compare
This allows breaking an import loop.
Per RFC 6455, "the masking key MUST be derived from a strong source of entropy." There is no such requirement Sec-WebSocket-Key but it seems better anyway.
It was too thin. It didn't add any value. Using the same abstractions for connection events and wire messages is good enough for our purposes.
In the new model, receive_data returns nothing and raises an exception on errors. Events received and bytes to send are obtained through other method calls.
|
This PR now contains a fairly complete Sans-I/O implementation of the WebSocket protocol. It doesn't include:
For all the usual reasons against long running branches with huge changes, I'm planning to merge this now. |
2 participants
Fix #466.