Text File
design.txt

Sessions

Sessions provide a way to temporarily associate information with a client without requiring the authentication of a principal. We associate an identifier with a particular client. Whenever we get a request from that client, we compute the identifier and use the identifier to look up associated information, which is stored on the server.

A major disadvantage of sessions is that they require management of information on the server. This can have major implications for scalability. It is possible for a framework to make use of session data very easy for the developer. This is great if scalability is not an issue, otherwise, it is a booby trap.

Design Issues

Sessions introduce a number of issues to be considered:

Application programming interface

Application code will merely adapt request objects to a session data interface. Initially, we will define the session data interface ISession. It provides a mapping interface. Keys in the mapping are application identifiers. Values are persistent mapping objects.

Application code that wants to get object session data for a request adapts the request to ISession:

appkey = "mycorp.actionplan"
data = ISession(request)[appkey]

where appkey is a dotted name that identifies the application. Given the session data, the application can then store data in it:

data['original'] = original_actions
data['new'] = new_actions

From ZPT, you can access session data using adapter syntax:

request/session:key

So, for example, to access the old key for the session data for the sample key above:

request/session:mycorp.actionplan/old

In this example, the data for an aplication key was a mapping object. The semantics of a session data for a particular application key are determined by the session data type interface. ISession defines the application data to be a mapping object by default. Other data interfaces could specify different bahavior.