Nick wrote:
Jim Gallacher wrote:
Just so I'm *really* clear, do you mean the current scheme for session
handling would also be disabled?
The more I think about it, you're right; you can just set up the session
stuff without directives just the same by importing mod_python.Session
and going from there. So that line of reasoning has no merit.
I was confused by the adding of a new directive, which seems to indicate
that there would be some "default" Session handler being loaded if you
didn't specify one using the directive.
In the new scheme, a session is created when the user calls
req.get_session(). The parameters used for creating this session are
specified in the apache config file. Contrast this with the current
mechanism where a new session is created when the user calls
Session.Session(), and the parameters are for the session must be passed
in the session initalization.
eg.
New way:
sess = req.get_session()
Old way:
sess = Session.FileSession(req,timeout=100,
session_directory='/tmp/sess')
With the new way, the first call to req.get_session() returns a new
session instance (loads one from the persistent store). Subsequent calls
within the same request will return the *same* instance. Users no longer
need to worry about session lock management, and our deadlock issues
disappear. Using sessions will be much more transparent. Sticking the
session parameters in the apache configuration keeps the get_session()
call simple, and easily accomodates future changes to the underlying
session code.
Because in the old scheme there
wasn't really any "default" session handling, unless you outright
imported the libary and started using it. If it's going to work exactly
the same way as it did before, except now you can configure some
defaults in the apache config, then I'm probably worried over nothing.
But it probably should have an option for "None" or "disabled," which
would be the default, meaning I don't care to use the supplied session
handlers, even though it didn't really do anything extra than it does now.
Indeed, as long as you don't call req.get_session(), there will be no
session created. You may be thinking that every request automatically
creates a session object. This is emphatically not the case. This would
be a performance killer.
But in that case, why not use "PythonOption session_<config_var>
<value>", which is probably what you were asking about in the first
place, which I think someone else mentioned as well. That doesn't imply
that there is some kind of default session handling, just the standard
way of passing values from the apache config to python code.
I hope that the PythonSessionOption just makes it really obvious that
this directive is for session configuration. And certainly the lack of a
"PythonSessionOption session some_session_class" line in the apache
config tells the admin that there is no default session. The question
then becomes, if the above directive is missing should req.get_session()
still return some platform dependent session (just as Session.Session()
currently does), or should it raise an exception?
If the
plan is to implement a pure C session handler,
No immediate plans, but I have thought of it. I've actually been doing
some benchmarking on a SQL backend as well. This is of course completely
off topic.
then PythonSessionOption
makes sense, but otherwise it doesn't seem necessary.
My motivation for creating the new PythonSessionOption directive rather
than using the PythonOption is as follows:
1. Avoid breaking exisiting code. It's impossible to predict how people
may be currently using PythonOption. I feel it's better to leave current
configurations untouched to completely avoid possible keyword
collisions. This is the *big* one for me.
2. Avoid breaking exisiting code, in case anyone missed point 1. :)
3. Easier to document and explain. Or maybe I'm actually making things
more confusing?
Maybe I need to write some docs with a tutorial before checking in the
code so people have a better idea what the heck I'm doing? I'm not
trying to force this directive on anyone - just trying to make session
handling better and it seems like a nice complement to the new
request.get_session() method.
Regards,
Jim
