Re: [boost] [Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)

Subject: Re: [boost] [Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-02-23 04:02:08

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.