Friday, January 28, 2011

Webstorage

Today me and Mathias spend the whole day trying to figure out how to fix the problems with the JavaScript API I talked about the other day. node-overwrite doesn't work for us, because it doesn't have to do much with the way we do things and only works for node.js

world-object

The main problem we had was that we wanted someway to map a erlang dictionary to a JavaScript object but couldn't figure out how to expose a host object to the JS-VM. Then Mathias said that it can't be possible to do it in a easy way because there are no variables in erlang, erlang is a functional language and you alway just get copies. Put it that way, even I got it why no one has done that before.

So we had to do it the erlang way, get a copy of the data, modify it and send a new copy back to erlang. I recalled a W3C specification called HTML5 Webstorage which tries to deal with exactly the same problem, to let the JS-Programmer to store data locally. This is their interface:

interface Storage {
  readonly attribute unsigned long length;
  getter DOMString key(in unsigned long index);
  getter any getItem(in DOMString key);
  setter creator void setItem(in DOMString key, in any value);
  deleter void removeItem(in DOMString key);
  void clear();
};

As you can see, it is not possible to store hierarchal data like Arrays or Hashes. So if you't like to do that, you'd have to serialize and deserialize the Array/Hash. At first we thought that this was a very dumb idea because it would take way too much time to do that. But then we had a look at the erlang_js implementation, because we wanted to know how they communicate between erlang and the JS-VM. Astonishingly they just use plain JavaScript stings via a socket to talk to a C-application which holds a instance of Spidermonkey and which just executes the string in Spidermonkey and if there is a return, returns this as a string back to erlang via this open socket connection.

Ok, now there was really no need to try to make it more complicated as it had to be and we decided that if you would like to store structured data like arrays or hashes in our key-value-localStore you'd have to use JSON.stringify() and JSON.parse().

That way we can offer a really easy to use API which people know from the JavaScript-Web-world. There is a good specification of that, example code en mass and there are many people you can ask. And we like the idea of using as many already available standards as possible.

Public and Private data

Obviously every time you use the setter or deleter method we will notify all clients about that. But what if you just want to save something which should not be distributed to all clients like some counter or other private data which no client should know about? Then we will, like the W3C proposes, offer a localStorage object which too saves the data persistently, but does not distribute it to all clients.

Last but not least there will be a Users array with all of the users who are logged in into this game. Every user-object will have at least an id, a nickname, and methods to talk to just to his client.

Time report

13 hours

2 comments: