David Fraser wrote:
Hi Nicolas, Jim
PythonSessionCreate as suggested is nice for flexibility, but scary for
non-coders - I like Jim's multiple options for that reason
I would argue that PythonSessionCreate is less flexible for users and
admins. It requires a knowledge of the mod_python package structure
(Session.FileSession), which will then get hard coded into the apache
configuration files. If we decide in the future to split the Session
classes into separate files, we'll break all existing configurations.
PythonSessionOption will likely only be used to override the existing
defaults defined in the code, so most configs will look like this:
PythonSessionOption session DbmSession
PythonSessionOption timeout 28800
I'll grant you that the config file will become cluttered with a larger
number of PythonSessionOption directives for more a complicated setup,
but the same problem exists for PythonSessionCreate. eg.
PythonSessionCreate
"Session.FileSession(session_directory='/var/lib/mod_python/sess',timeout=14400,secret='howdy',lock=1,fast_cleanup=1,verify_cleanup=1,graceperiod=20,this_string_is_hard_read=True)"
Using python code in the config file means the admin needs to worry
about proper quoting of the string. We should not assume that the admin
will be a programmer. I can imagine the mailing list questions, and
Graham already spends enough time answering questions. :)
I also think that parsing the PythonSessionCreate string will turn out
to be a difficult task to do in a really robust way.
And the real reason for using PythonSessionOptions? Through the magic of
cut and paste programming I was able to adapt PythonOptions/get_options
in about 5 minutes with high confidence it would work the first time. It
did. :)
As far as refactoring Session.py, I've already done this to some extent
in my attempts to track down the memory leak with the req_get_session()
method - not a big job. Most of the config handling code would be added
to BaseSession.__init__(). My personal preference if we refactor
Session.py is to go all the way and split it into a package right now.
We are making enough changes in the way sessions are used that I think
it is the correct time, rather than half now and half later.
mod_python.session2 anyone? Session.py becomes wrapper around the new
package structure for backwards compatability, and coders using release
>= 3.2.0 will use the PythonSessionOption, req.get_session() combo for
their new code.
Regards,
Jim
David
Nicolas Lehuen wrote:
Hi Jim,
Why not have a single 'PythonSessionCreate' option which contains the
line of code that should be evaled to create the session ?
Example :
PythonSessionCreate
"Session.FileSession(session_directory='/var/lib/mod_python/sess',timeout=14400,lock=1)"
The cost of eval could be brought down by precompiling the option
string to a code object and running the code object in precompiled
form.
This seems a bit more flexible to me and won't force you to refactor
the Session.py code.
Regards,
Nicolas
2005/6/12, Jim Gallacher <[EMAIL PROTECTED]>:
I've created a new apache directive called PythonSessionOption. This
would be used to configure session handling in the apache config file.
This data is accessed with a new request method,
req.get_session_options().
Although we could use the PythonOption directive instead of creating a
new one, I believe it's better to keep the session config data separate
so we don't need to worry about collisions with current user code or
configuration.
Typical Usage
-------------
In a test script mptest.py
def handler(req)
opts = req.get_session_options()
for k in sess_conf:
req.write('%s: %s' % (k,opts[k])
In Session.FileSession:
__init__(self,req,sid):
opts = req.get_session_options()
timeout = int(opts.get('timeout', DFT_TIMEOUT))
In an Apache config file:
<VirtualHost 192.168.1.12:80>
ServerAdmin [EMAIL PROTECTED]
ServerName example.com
DocumentRoot /var/www/
PythonSessionOption session FileSession
PythonSessionOption session_directory /var/lib/mod_python/sess
PythonSessionOption timeout 14400
PythonSessionOption lock 1
...
</VirtualHost>
If there are no objections I'll commit the code. I have not refactored
Sessions.py to use the new configuration scheme just yet.
Regards,
Jim
