search

gimite / web-socket-js

HTML5 Web Socket implementation powered by Flash
BSD 3-Clause "New" or "Revised" License
2.73k stars 488 forks source link

Why the dependence on FABridge? #12

Closed TooTallNate closed 14 years ago

TooTallNate commented 14 years ago

I'm just wondering why we're even using FABridge in this case? I mean, we only need to expose a couple methods to JavaScript, which could easily be accomplished with just ExternalInterface, and needing to include another (unneeded) script file is kind of a bummer. Is there something FABridge gives us that I don't know about? Thanks!

gimite commented 14 years ago

It's just to make implementation easier. We need both JavaScript -> Flash and Flash -> JavaScript (e.g. onopen) communication, and also we need to handle case where one script has multiple WebSocket objects. They are possible with ExternalInterface but easier with FABridge.

TooTallNate commented 14 years ago

Ahhh, I see. So if we were to rely on only ExternalInterface, then there would need to be a globally visible array of WebSocket instances for the Flash side to make callbacks to, and each instance would need and index.

I might fork and remove the dependance if I get the time, cause I'm nit-picky when it comes to bandwidth/loading time.

sippykup commented 14 years ago

Nate, this would also fix the memory leak (see issue 33), so would love to see FABridge dumped.