Sounds interesting.
Is this module just managing the sessionID or also the session data? i.e.
is the manager capable of storing complex objects (via something like
Storable or Data::Dumper)? Will you provide hooks "caching and DB
abstraction" layers so that the developer can provide the backend
implementation?
~J
----- Original Message -----
From: "Greg Cope" <[EMAIL PROTECTED]>
To: "Modperl list" <[EMAIL PROTECTED]>
Sent: Sunday, September 10, 2000 2:40 PM
Subject: [ RFC ] A Session Manager module
> Dear All
>
> As some of you are aware for the past few weeks I have been working on a
> Session Manager style module.
>
> It works (ish ;-), I know of a few issues (that may not be important
> enough to change), but it works in my developement environment.
>
> What do I do with it now ? I think it may fit in well as a front end to
> Apache::Session, although it needs a name. Its only around 400 lines
> (including some POD and comments).
>
> It could fit in quite well with Apache::Session (ie providing a session
> id, and Apache::Session does the server side storage). It may also fit
> in with other implementations such as Embperl, Apache::ASP, and Mason -
> although most of these have their own implenetations.
>
> My original plan - believe it or not - was to write a short "how to"
> style tutorial to creating a mod perl shopping cart, the idea was not to
> have another shopping cart, as there are many other better
> implentations, but to have a few reasonably easy examples of mod_perl in
> a real world type example. This was inspired by someones post a few
> months back for documentation / articles etc. Well I started and wrote
> a few modules, and went on to create a templating module (as per any
> true path to mod_perl wisdom!), this session module and a DB abstraction
> layer (and aparently I should be creating a caching module as well!).
>
> Well any ideas - please let me know.
>
> Greg Cope
>
>
> A few details below.
>
> AIM:
>
> To manage session ID's between client and server - to get (or optionally
> set) a sesion id via Cookies, Mungled URL or path_info.
>
> Implemetation:
>
> Uses a transhandler.
> Optional configurations to alter logic / options via a package scalar eg
> (some but not all) in a startup.pl:
>
> use SessionManager();
>
> $SessionManager::DIR_MATCH = '/foohandler'; # default is match
> everything of /\.html/ !
> $SessionManager::REDIRECT = 1; # default to no
> redirect
> $SessionManager::DEBUG = 7; # default debug is off
> $SessionManager::SESSION_ID_LENGTH = 32; # nice long ID lenght
> $SessionManager::NON_MATCH = '\.gif|\.jpeg|\.jpg'; # ignore images
>
> i.e. the above will session manager a URI matching 'foohandler', if
> cookies are off it will redirect and set an mungled URI with a session
> id length of 32 - it will also dump loads of debug info (between 3 and
> 20 lines a request), and ignore any gifs, jpegs, and jpg files within a
> URI 'foohandler'.
>
> Also:
>
> $SessionManager::COOKIES_ONLY = 1;
>
> Will only try cookies and then stop
>
> $SessionManager::ARGS_ONLY = 1;
>
> Will only try ARGS (after cookies).
>
> $SessionManager::URI_FIRST = 1;
>
> Try URI (mangled) after cookies, before ARGS, this allows changing the
> order of which things are checked.
>
> $SessionManager::USE_ENV = 1;
>
> Instead of using pnotes entries use Environmental variables.
>
> There are aslo a few other bits in the works for trying to setting a
> cookie if they are off by redirecting, and then using a mangled URI or
> ARGS if that failed - this will have a TTL, and DOMAIN vars that will
> allow overriding of the defaults.
>
> Thats about it.
