Thank God someone else is as anal as me to have brought this up also (I
think I did a few months ago). I thought I was alone. :)
Anyway... I have lately been thinking of the abstractions because I wrote
a wrapper around Apache::Session for Extropia::Session.
Really, the issue is getting the abstraction correct. I think, to some
degree, that perhaps Jeffrey is right to have removed the cookie/session
management stuff...
This is because you have different data stores for the sessions : files,
dbi, etc... But then you don't want to tie in the cookie and other session
management routines in the sessions or you will end up with a cartesian
product of classes (or some weird multiple iheritence hierarchy that I
would not recommend).
There are of course a few different ways to handle in the issue. One way
is a wrapper. In this case, what you want is something that is managing
Sessions (a SessionManager object) which then creates
SessionManager::Cookie or SessionManager::Form orwhatnot depending on the
strategy.
Another way to do it, is to actually handle it all as an API to session,
but pass a SessionStrategy object to the Session which gets created
polymorphically to determine how the session is generated.
I prefer leaning towards a wrapper to the persistent hash. THen it has
tobe clear that the APache;session object can be polymorphically created
via run-time require vs compile-time use.
Anyway, it's kind of driven me a bit mad because I'm doigthis for
Extropia::Authentication (for pluggable auhentication modues on a CGI
level (not a mod_perl level). And there are a varity of ways to deal with
this as well. But one thing that has stood out in my rewrites is that I
prefer late binding in Perl to compile time when dealing with Sessions
because it allows the freedom to change the strategies in a setup file at
will instead of hunting for hardcoded use Sessin::File and new
Session::File()... type of stuff. It's better to say
new Session(-TYPE => "File", ...params to file session)..
Rather then all the compile time binding. If you preload the module in
mod-perl youdon't lose anything anyway. And if you stick to a pure OO
interface then the exports don't matter.
Anyway, the bottom line is that I think Jeffrey is right to have been
frustrated putting everything in one hierarchy. However, perhaps rather
than taking it out, a different abstraction would have been interesting.
To tell you the truth, cookie or form manaement of hidden varables and the
like is code I see rewritten from scratch a lot of different places EXCEPT
Servlets and ASPs typically. ..
Why? Because programmers definatley take advantage of that you give them.
BTW, I do think an expiry api should be in core session though still. But
not necessarily to have it expire automatically (That could still be
session manager domain). However, it would be nice to have an API that [a]
Enumerates the sessions that exist, [b] gives a last accessed and a
created time stamp return, [c] allows forced removal of a sesion id hanle
that got enumerated over.
Then the SessionManager can easily take care of the logic of how to expire
sessions or to do other things with them like querying ll the sessions for
a prticular user value or anything else a CGI author might want to do even
in weird circumstances.
Later,
Gunther
On Thu, 14 Oct 1999, Jeffrey Baker wrote:
> Dmitry Beransky wrote:
> >
> > I've been going through the code of Apache::Session trying to understand
> > how it works and how to use it when it occurred to me that the module
> > doesn't really measure up to it's name. I mean IMHO, the name is a bit
> > misleading.
> >
> > First. It looks like the module's code is completely self-contained and
> > doesn't depend on anything Apache. If my observations are true, why is it
> > in the Apache hierarchy (except possibly for historical reasons)?
>
> Yes, the name is purely historical. In reality, Apache::Session is a
> persistence framework with multiple interchangable backing stores. You
> still need to build your session management logic around it.
>
> I tried to implement actual session management in the original 0.1x
> Apache::Session series, but it was unworkable. Some people wanted
> expiration, some people didn't. Some wanted cookies, others wanted
> extended path information. I found it much more pleasing to simply
> implement the part that everyone needed (storage management) and leave
> the twidly little details up to the programmer.
>
> If you want an environment that gives you session handling for free,
> check out one of the many nice mod_perl toolkits, such as Embperl,
> Apache::ASP, and HTML::Mason (?). Embperl makes use of Apache::Session,
> but I don't know what implementation the others use.
>
> > Second. It doesn't really manage sessions. It provides implementations
> > for different models of persistent storage (memory, FS, DB, etc.). A
> > complete Apache-based session managing mechanism (with session
> > initialization, destruction, auto-expiration, etc.) still has to be coded
> > on top of it.
> >
> > Any comments? Shouldn't it be renamed?
>
> Possibly, but I don't know what the mechanics of moving a module are,
> and I can't think of a good name anyway. Perhaps Persistent::Hash?
>
> > Regards
> > Dmitry Beransky
>
> -jwb
> --
> Jeffrey W. Baker * [EMAIL PROTECTED]
> Critical Path, Inc. * we handle the world's email * www.cp.net
> 415.808.8807
>
