[Gas] Re: Adding 'session variables' to gas

[Zachary C.Miller]

> What (again) are the various ways that one can add a 'session variable'
> in Gas? I know you've told me this before, but I'm having a memory
> blank. By 'session variable' I just mean a variable which hangs around
> for more than one page. 

There are several answers to this question of varying levels of
elegance and with varying pros and cons: 

1. Do it in an application specific way by sticking stuff in some
   database table that is keyed on the user login and has custom
   columns for the various interesting variables. This doesn't create
   a "session" but it associates sticky information with a given login
   which may be better or worse than a session depending on what you
   want. Of course you can't have any session variables when the user
   isn't logged in if you use this method.

2. Just use normal HTTP cookies with the OutputManager's set_cookie()
   routine. 

3. Use the Gas::add_url_param() routine to add paramters to the all
   future url's generated by the Gas::url routine. This is a good way
   to basically propagate session variables via CGI parameters. With
   URLs generated this way the parameters encoded in the URLs will end
   up in bookmarks and in URLs emailed to friends which may or may not
   be something you want. Note that you have to call add_url_param()
   for the params you want to preserve on every request so generally
   it is a good idea to put the logic for this in your .cgi driver
   script.

4. Create a SessionManager that uses a single HTTP cookie session key
   along with a database that holds a serialized hash for every
   session key. (more on SessionManager design below) SessionManager
   is not currently implemented.

Here is the text of an email I once sent to Bill (complete with
original typos):

There is no SessionManager at this time. Sigfried and Bob and I were
just talking about how one might be built but currently it doesn't
exist.

When I has a system with logins I tend to just stash information in a
custom table keyed by the person's login id. That way it is tied to
their login rather than to a particular session with a particular
browser so if they stop and come back later from a different place the
state is the same.

But if you really want a generic session variables thing I would
suggest adding a SessionManager to Gas. Shouldn't be too much work. I
will be at OJC by 1pm today (probably sooner, but I do have a bunch of
errands to run). If you want I can take some time to sketch/review the
API for such a beast with you.

My first guess would be that the session manager would be something
like this:
Session data is a 5-tuple <session_key, data_key, serialized_data, ctime, atime, mtime>

<session_key, data_key> picks out an item of data.

The session_key is set as a cookie and added into the default URL
parameters. Look at how AuthManager handles the gas_auth_cookie for an
example.

The data_key picks out a specific variable for the session.

The serialized_data is Data::Dumper'ed version of any arbitrary data.

The ctime is the time when the item was created, the mtime is the last
modified time for the item, and the atime is the last accessed
time. These could be used to expire the data from the table in a
cronjob if desired.

methods:

new - a constructor, takes a reference to the Gas object, DBManager
and to the CGI object and optionally the name of the session
table. The constructor looks at the CGI environment and checks to see
if the session_key was provided on the URL or as a cookie. If so it
uses that, if not it getnerates a new one. I would suggest using the
current $ENV{UNIQUE_ID} as the new session key so that every session
is named after the key of its root request...this could be useful for
statistics/debugging. Anyway then it makes sure the session key is
registered as a default URL parameter with Gas. Lots of this kind of
stuff happens in AuthManager.

data - an accessor/mutator, if given a key and a reference adds that
reference (after Data::Dumper'ing or otherwise serializing it) to the
database at that data_key (for the current session_key). if only given
a key returns the unserialized version of hte data at that key in the
database.

init_table - called by an install script to initially set up the table.

The SessionManager would be constructed riht after the DBManager in
the driver script.

SessionManager might be implemented in 2 files, Gas/SessionManager.pm
and Gas/DB/SessionTable.pm where SessionTable inherrits from DB::Base
but overrides "new" so that it can optionally take a table name which
the table() routine would return rather than a hardcoded default.  But
other than that it would be just like a regular DB file.

-- 
Zachary C. Miller - @= - http://wolfgang.groogroo.com/
IMSA 1995 - UIUC 2000 - Just Another Leftist Muppet - Ya Basta!
 Social Justice, Community, Nonviolence, Decentralization, Feminism,
 Sustainability, Responsibility, Diversity, Democracy, Ecology