Warning:
This wiki has been archived and is now read-only.
Web Storage
Introduction
As for today, getters and setters of items in this API are purely synchronous. There might be no impact in async environments like node.js if the storage is all cached in memory. Still, some events exists to inform other threads (workers, windows...) when an item is updated
Contacts
We are looking for representatives of this HTML5 API to discuss of potentially needed updates to consider server-side implementations
Debate
The current Issue in the Web Storage Recommendation is about data collisions:
- The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable. Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after. If reviewers have any suggestions, they are urged to send them to the addresses given in the previous section.
What is acceptable here on client-side might not be acceptable on an application server which might need some lock mechanisms
SSJS Implementations
SessionStorage is a very good candidate to manage sessions on the server.
Wakanda
Wakanda Server implements SessionStorage as well as the global "storage" (an application level memory store) and "user.storage", both implementing the Web Storage interface
lock() and unlock() methods have been added to prevent collisions. As for today, such collisions might happen in the browser if there is multiple windows or worker contexts.