Re: PythonSessionOption - a new apache directive for session configuration

2005-06-15 Thread Nick
How about an explicit None value to completely disable it?  If you don't 
want users on your site using it.


Nick

Jim Gallacher wrote:

So, any further thoughts / comments / objections to PythonSessionOption,
 or shall I just check in the code?

Regards
Jim


Jim Gallacher wrote:

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








Re: PythonSessionOption - a new apache directive for session configuration

2005-06-13 Thread Jim Gallacher

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