Please review, any comments are welcome. The docs still need improvement, working on that.
Trying to do this one from the specs results in the same sorry mess as Engine.IO. So this again is the result of "specs" combined with a lot of protocol reverse engineering.
The implementation (of both EngineIO and SocketIO) is supposedly threadsafe now. It passes all tests.
I'm adding an event layer on top now (as similar as possible to the one that the javascript Socket.IO provides).
The dust is starting to settle.
Stephen R. van den Berg wrote:
I'm adding an event layer on top now (as similar as possible to the one that the javascript Socket.IO provides).
The eventlayer turned out to be so thin, that I integrated it instead of layering it on top. The SocketIO-rooms seem to be a pretty useless feature, it mostly helps when you want to create an IRC-replacement, but does not feel like belonging in a driver of sorts. If anyone has other ideas about this, let me know.
Time to work on the docs now.
If anyone has API remarks, (un)desirabilities, now is the time to speak up!
The dust has settled (somewhat).
The docs are complete in their first draft.
Still have to figure in the variant declarations for stricter typechecking. Time to use it in my own project.
Most bugs have been eradicated, significant further API changes are unlikely.
I'm using it in a mini-application here now. I.e. in my application I define two namespaces:
"" : Authentication functions. Supported RPC (Remote Procedure Call) events are: - client->server: "gettoken" - server->client: "getusername", "getpassword".
"db" : Connects to a database. Supported RPC events are (all client->server): - "gettoken" (used internally, server->server). - Any other queries the user-application needs.
Other namespaces could be defined for other server functions (like controlling hardware).
In essence this framework allows me to do asynchronous database queries from a webbrowser application with minimal overhead.
pike-devel@lists.lysator.liu.se
-
Stephen R. van den Berg