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

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

2 files changed, 22 insertions, 45 deletions

diff --git a/docs/TODO b/docs/TODO
index e8d1200..87f786f 100644
--- a/docs/TODO
+++ b/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
+
+Medium Term:
+
+- VNC performance and regression playback suite.
+
+- Viewport support
+
+- Touchscreen testing/support.
 
-Longer Term:
+- wswrapper:
+    - epoll_* support
 
-- Get web-socket-js RFC2817 proxying working again.
diff --git a/docs/notes b/docs/notes
index b41d56d..b3cc0cf 100644
--- a/docs/notes
+++ b/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: