On 02/22/2010 03:51 AM, Daniel Trebbien wrote:
From the rationale page of the documentation, it appears that one of the intended applications of a tokenmap is in the implementation of state management on top of an otherwise stateless protocol (such as HTTP).
With HTTP, a common trick of tracking state (whether a user is logged in, their username, etc.) is to set a cookie that contains a session id. The client stores the session id and the server serializes all state data, saving it on the server side, and associates this data with that id. For each subsequent HTTP request by the client, the client sends the session id to the server, which then finds the serialized data.
The server can not trust anything that the client sends, so the server needs a way to verify the id. At a minimum, an associative container of some sort is needed that maps the session id (token) to the serialized data. To safely use an iterator or a pointer to the inserted element, the server would need a separate map from tokens to iterators. The tokenmap solution combines the two maps that would be involved (token to session data and token to iterator into the other map, with the token-to-iterator map being extremely fast in performing lookups).
In that case I would prefer the token generation mechanism to be separated from the container structure. This would enable users to use tokens in different containers, from STL to Boost.MultiIndex and Boost.Intrusive. The proposed tokenmap would be equivalent to the standard unordered containers with the tokened values then.