Save notes

Author: invisibleroads

missions/PullRequests-20160331-1233.md

@@ -119,9 +119,22 @@ If the exception appears again, then we'll use atexit.register(self._heartbeat_t
 
 The issue is that packet_text has utf-8 but we need a bytestring and six.b only encodes using latin-1.
 
-    _ Option 1: Encode packet_text into a bytestring using utf-8, but then we won't be working with unicode.
+    Option 1: Encode packet_text into a bytestring using utf-8, but then we won't be working with unicode.
     Option 2: Leave packet_text alone and handle it differently based on whether it is unicode or a bytestring.
 
 20160715-1315
 
 After thinking about it a bit, I think the second approach is more robust, because we'll just leave the packet data as it is mostly and just handle it verbatim. The first option can be vulnerable to cases where the packet type might be wrong?
+
+20160715-1700
+
+If I ever do revisit binary support, I should try to generate a log of the binary protocol using Chrome Developer Tools. There were some notes about XHR2 vs base64.
+
+- https://github.com/socketio/engine.io-protocol
+- https://github.com/socketio/socket.io-protocol
+
+The feus4177 repository has a working solution for binary support, but I didn't completely understand how it worked and I felt uncomfortable about merging something without full understanding.
+
+I also wanted to address unicode support and the decision was to keep everything as an encoded bytestring and only decode for non-binary events. I tried the approach of leaving the packet alone and just handling unicode or bytestring on a case by case basis, but it proved too messy.
+
+Perhaps when my life becomes less complex, I'll revisit both binary and unicode support. But for now, I have too many things in my head and my capacity for extra complexity is becoming rather limited.