utils/README.md, docs/TODO, docs/notes: updates.

Add wswrapper info to utils/README.md and docs/TODO. Remove innacurate
info from docs/notes.

docs/TODO

@@ -1,19 +1,10 @@
 Short Term:
 
-- Playback/demo on website.
-
-- VNC performance and regression playback suite.
+- Keyboard layout/internationalization support
+    - convert keyCode into proper charCode
 
 - Test on IE 9 preview 3.
 
-- Fix cursor URI detection in Arora:
-    - allows data URI, but doesn't actually work
-
-
-Medium Term:
-
-- Viewport support
-
 - Status bar menu/buttons:
     - Explanatory hover text over buttons
 
@@ -29,7 +20,20 @@ Medium Term:
     - Clipboard button -> popup:
         - text, clear and send buttons
 
+- wswrapper:
+    - Flash policy request support.
+    - SSL/TLS support.
+    - Tests suite:
+        - test pselect/poll/ppoll
 
-Longer Term:
+Medium Term:
+
+- VNC performance and regression playback suite.
+
+- Viewport support
+
+- Touchscreen testing/support.
+
+- wswrapper:
+    - epoll_* support
 
-- Get web-socket-js RFC2817 proxying working again.

docs/notes

@@ -4,39 +4,12 @@ There is an included flash object (web-socket-js) that is used to
 emulate websocket support on browsers without websocket support
 (currently only Chrome has WebSocket support).
 
-The performance on Chrome is great. It only takes about 150ms on my
-system to render a complete 800x600 hextile frame. Most updates are
-partial or use copyrect which is much faster.
-
-When using the flash websocket emulator, packets event aren't always
-delivered in order. This may be a bug in the way I'm using the
-FABridge interface. Or a bug in FABridge itself, or just a browser
-event delivery issue. Anyways, to get around this problem, when the
-flash emulator is being used, the client issues the WebSocket GET
-request with the "seq_num" variable. This switches on in-band sequence
-numbering of the packets in the proxy, and the client has a queue of
-out-of-order packets (20 deep currently) that it uses to re-order.
-Gross!
-
-The performance on firefox 3.5 is usable. It takes 2.3 seconds to
-render a 800x600 hextile frame on my system (the initial connect).
-Once the initial first update is done though, it's quite usable (as
-above, most updates are partial or copyrect). I haven't tested firefox
-3.7 yet, it might be a lot faster.
-
-Opera sucks big time. The flash websocket emulator fails to deliver as
-many as 40% of packet events when used on Opera. It may or not be
-Opera's fault, but something goes badly wrong at the FABridge
-boundary.
-
 Javascript doesn't have a bytearray type, so what you get out of
-a WebSocket object is just Javascript strings. I believe that
-Javascript has UTF-16 unicode strings and anything sent through the
-WebSocket gets converted to UTF-8 and vice-versa. So, one additional
-(and necessary) function of the proxy is base64 encoding/decoding what
-is sent to/from the browser. Another option that I want to explore is
-UTF-8 encoding in the proxy.
-
+a WebSocket object is just Javascript strings.  Javascript has UTF-16
+unicode strings and anything sent through the WebSocket gets converted
+to UTF-8 and vice-versa. So, one additional (and necessary) function
+of wsproxy is base64 encoding/decoding what is sent to/from the
+browser.
 
 Building web-socket-js emulator:
 

utils/README.md

@@ -53,32 +53,36 @@ These are not necessary for the basic operation.
 
 #### Implementations of wsproxy
 
-There are three implementations of wsproxy included: python, C, and
-Node (node.js).
+There are three implementations of wsproxy: python, C, and Node
+(node.js). wswrapper is only implemented in C.
 
-Here is the feature support matrix for the wsproxy implementations:
+Here is the feature support matrix for the the wsproxy implementations
+and wswrapper:
 
 
 <table>
     <tr>
-        <th>Implementation</th>
-        <th>Basic Proxying</th>
+        <th>Application</th>
+        <th>Language</th>
+        <th>Proxy or Interposer</th>
         <th>Multi-process</th>
         <th>Daemonizing</th>
         <th>SSL/wss</th>
         <th>Flash Policy Server</th>
         <th>Session Recording</th>
     </tr> <tr>
+        <td>wsproxy</td>
         <td>python</td>
-        <td>yes</td>
+        <td>proxy</td>
         <td>yes</td>
         <td>yes</td>
         <td>yes 1</td>
         <td>yes</td>
         <td>yes</td>
     </tr> <tr>
+        <td>wsproxy</td>
         <td>C</td>
-        <td>yes</td>
+        <td>proxy</td>
         <td>yes</td>
         <td>yes</td>
         <td>yes</td>
@@ -86,14 +90,25 @@ Here is the feature support matrix for the wsproxy implementations:
         <td>no</td>
     </tr>
     </tr> <tr>
+        <td>wsproxy</td>
         <td>Node (node.js)</td>
-        <td>yes</td>
+        <td>proxy</td>
         <td>yes</td>
         <td>no</td>
         <td>no</td>
         <td>no</td>
         <td>no</td>
     </tr>
+    </tr> <tr>
+        <td>wswrapper</td>
+        <td>C</td>
+        <td>interposer</td>
+        <td>indirectly</td>
+        <td>indirectly</td>
+        <td>no</td>
+        <td>no</td>
+        <td>no</td>
+    </tr>
 </table>
 
 * Note 1: to use SSL/wss with python 2.5 or older, see the following