- 17 Jul, 2010 1 commit
-
-
Joel Martin authored
The listen port should be opened before daemonizing otherwise if opening the port fails, the user will get no feedback. The only complication was that the listen socket needs to not be closed as part of daemonizing. Thanks to http://github.com/rickr for finding it.
-
- 16 Jul, 2010 5 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
Add new states 'loaded', 'connect' and 'fatal': - Loaded state is first page state. Pass WebSockets mode message using this state. - Connect indicates that the user has issued a "connect" but we haven't gotten an WebSockets onopen yet. - Fatal is a condition that indicates inability to continue on: right now, lack of WebSockets/Flash or non-working canvas. Move much of the actual state transition code into updateState. Handle 'password' state better in default_controls.js; instead of disconnecting, prompt for password to send. Add comments to updateState indicating possible states.
-
Joel Martin authored
-
- 15 Jul, 2010 1 commit
-
-
Joel Martin authored
-
- 14 Jul, 2010 1 commit
-
-
Joel Martin authored
0 is valid UTF-8, but in order to avoid WebSockets framing, we encode/decode it as 256. Also, be tolerant of 0 length messages.
-
- 13 Jul, 2010 2 commits
-
-
Joel Martin authored
Interestingly it turns out that using the native base64 routines does not improve performance. Likely because the actual time is in marshalling/unmarshalling between strings and arrays (and associated garbage collection overhead) which has to be done either way.
-
Joel Martin authored
- Change tightpng encoding number to -260 (aliguori provided it until an official number can be allocated).
-
- 09 Jul, 2010 4 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
- 07 Jul, 2010 3 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
- 06 Jul, 2010 3 commits
-
-
Joel Martin authored
-
Joel Martin authored
mootools is no longer needed. The bug that the FABridge test was testing has been resolved in web-socket-js so it's no longer needed.
-
Joel Martin authored
Util.Debug, Util.Info, Util.Warn, Util.Error routines instead of direct calls to console.*. Add "logging=XXX" query variable that sets the logging level (default is "warn"). Logging values: debug: code debug logging (many calls in performance path are also commented for performance reasons). info: informative messages including timing information. warn: significant events error: something has gone wrong
-
- 05 Jul, 2010 1 commit
-
-
Joel Martin authored
-
- 02 Jul, 2010 10 commits
-
-
Joel Martin authored
Also, move bugs from TODO to github issues.
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
Bug fixes, restore RFC2817 proxy for non wss://, and handle new closing handshake from WebSockets 76.
-
Joel Martin authored
The problem is, you can't set WebSocket.__swfLocation before you load web_socket.js (because it creates the WebSocket global), but you also can't reliably set WebSocket.__swfLocation after because if you are doing dynamic script file includes then the onload (i.e. WebSocket.__initialize) may fire before you have a chance to set Websocket.__swfLocation.
-
Joel Martin authored
Bug fixes, restore RFC2817 proxy for non wss://, and handle new closing handshake from WebSockets 76.
-
- 01 Jul, 2010 9 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
Brings it up to date with the most recent web-socket-js event handling fixes.
-
Joel Martin authored
Add message/state pollling in web-socket-js. Since Opera tends to drop message events, we can dramatically increase performance by polling every now for message event data. Also, add more direct calls to update readyState so that it's not missed when Opera drops events.
-
Joel Martin authored
At connect and close time instead of initialization time.
-
Joel Martin authored
When using web-socket-js, the onopen event may happen inline so the caller may not have time to set onopen before the event fires. In this case set a short timeout and try again. In particular this affects Opera most of the time. Also, to get around Opera event droppings, always read the readyState directly instead of relying on the local readyState variable to be correct (which it isn't if stateChange event were dropped).
-
Joel Martin authored
All browsers with Canvas imageData are faster with JS ops instead of canvas ops. This gives significant performance improvement in Opera. Except for missing web-socet-js message notifications, Opera 10.60 is now faster than firefox 3.5.
-
Joel Martin authored
Instead of relying on FABridge AS -> JS event delivery, we just use the events to notify JS of pending data. The message handler then calls the AS readSocketData routine which sends back an array of the pending WebSocket frames. There is still a minor bug somewhere that happens after the first connect where the web-socket-js throws an "INVALID_STATE_ERR: Web Socket connection has not been established". But, Opera is now usable and we should be able to drop the packet sequence numbering and re-ordering code. Another minor issue to better support Opera is to move JS script includes to the <head> of the page instead of after the body.
-
Joel Martin authored
Pull in LGPL md5.c and md5.h files (written by Ulrich Drepper). Now both python and C version of the proxy support both protocol 75 and protocol 76 (hybi 00). Reorganize websocket.py slightly to match websocket.c.
-