Server interface
1. Initiation phase (init the whole game, etc.)
2. User login/logout
3. Messaging phase, events from client to server and from server to client
World API (JavaScript)
In Spidermonkey we don't have the objects a browser exposes like document or window. But we'll have our own like "user" and "world". We will implement some functions we think are important but not present in
JSAPI like setTimeout().
The user object will only be a readable array of all users with their data. All the data is saved in erlang as a dictionary. The world object will be read and writable, here too all the data will be stored in erlang.
Spidermonkey allows you to use your own
setters and getters, that way it will be no problem for us to use them to store the data in erlang like for example:
world.a = 1;
which would call a setter we implement which talks to erlang and stores the key value pair. That way we'd have a really nice and clean JavaScript-like API.
Internal interfaces
This needs to be evaluated further, but we want to use our own spidermonkey shell for security reasons and pipe between it and our erlang server. We will save all the worlds and users and stuff in a
ETS instance
One of the main goals is to get everything non blocking so we can serve huge amounts of clients and games.
Time report
9 hours
I liked the first version better!
ReplyDeleteI can see the 'det var bättre förr' -syndrome is spreading across posts!
ReplyDeleteAbout the users array, can we make it read-only? Is this possible in spidermonkey/JS?
ReplyDeleteYes it is possible in Ecmascript 5 and should have been implemented in the latest Spidermonkey http://ejohn.org/blog/ecmascript-5-objects-and-properties/
ReplyDelete