- web-socket-js is from http://github.com/gimite/web-socket-js. It is
  a flash object that emultates WebSockets.

Unfortunately, events (or packets) from the web-socket-js object can
get re-ordered so we need to know the packet order.

- So wsproxy.py prepends the sequence number of the packet when
  sending.

- If the client receives packets out of order it queues them up and
  scans the queue for the sequence number it's looking for until
  things are back on track. Gross, but hey: It works!

- Also, add packet sequence checking to wstest.*

web-socket-js is a flash based WebSockets emulator.

From: http://github.com/gimite/web-socket-js

Apparently both native and flash WebSockets implementations can send
partial packets.

- Also slightly better performance.

- A textarea below the VNC area represents the state of the current
  VNC clipboard. If there is a server cut event, the textarea will be
  updated. If the user updates the contents of the textarea, the new
  data will be sent as a client paste (cut) event.

- One important change was to detect if the clipboard is focused and
  allow the user to type in the clipboard instead of in the VNC area.

- raw encoding displays horizontal lines as they arrive for better
  feedback and less time hanging waiting for something.

- Mouse movements are accumulated and sent about 5 times a second.
- Normal polling happens at about 1.5 seconds intervals.

This commit represents a very functional VNC client under Google
Chrome.

Remaining work:

    - Cut and paste support.

    - Framing bugs when using RRE encoding.

    - Better status and error feedback.

    - Get working in firefox using flash web-socket-js:
        http://github.com/gimite/web-socket-js

    - Version without mootools (but test cross-browser).

- Also, try making set fillStyle called less often.

- Many times better performance. Before this, browser was spending all
  it's time garbage collecting or doing something. Now the bottleneck
  is in set fillStyle and fillRect which is probably where it should
  be.

- Refactor to pull off all the data received into RFB.d array and then
  process it. This allows a bit more flexibility in handling
  data that isn't sent in frame boundary packets.

- Properly ignore these server messages: SetColourMapEntries, Bell,
  ServerCutText.

- Hextile has an undocumented weirdness where RAW frames are often
  followed by a 0 byte that should be ignored.

- Coallesce client messages that are one after another. Without
  this the server seems to often ignore frames that are send right
  after another frame has been sent. This fixes a reconnect issue
  where setEncodings seems to be ignored. Also results in a huge
  performance increase after key strokes (by adding a update request
  to the key event message) because the server always sends an update
  instead of sometimes waiting for the next poll to be sent.

With hextile you can't know how many bytes are pending. So restructure
so that all the received data so far is passed to the processsing
routines.

- Prime number background worker that can be started, stopped and
  reset that calculates prime numbers and sends them back to the main
  page/thread.