I hope there will be some nice examples and documentation to go with
this new session package/implementation.

On Mon, 2005-06-13 at 08:53 -0400, Jim Gallacher wrote:
> David Fraser wrote: 
>
> 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,t
his_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 
> their new code.
>
> Regards,
> Jim
> 
>

[ Post a follow-up to this message ]