quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: [Mod_python Wiki] Update of "Session use with classes" by MartinStoufer
Date Sat, 02 Dec 2006 03:43:00 GMT
Martin Stoufer wrote:
> 
> 
> Jim Gallacher wrote:
>> Apache Wiki wrote:
>>> Dear Wiki user,
>>>
>>> You have subscribed to a wiki page or wiki category on "Mod_python 
>>> Wiki" for change notification.
>>>
>>> The following page has been changed by MartinStoufer:
>>> http://wiki.apache.org/mod_python/Session_use_with_classes
>>>
>>> The comment on the change is:
>>> A good start.
>>>
>>> ------------------------------------------------------------------------------

>>>
>>>     Once you understand this framework, you can then add your own 
>>> content.
>>>   - First, lets augment a directory element in the ''httpd.conf'' to 
>>> enable session support.
>>> + First, lets augment a directory element in the ''httpd.conf'' to 
>>> enable both the Publisher model and session support.
>>
>>> +     PythonOption session MemorySession
>>
>> I'm not sure about the most elegant way to handle this in the wiki, 
>> but we likely need to make the reader aware of differences between 
>> mod_python versions.
>>
>> Using this "PythonOption session" as an example, we actually have 3 
>> different cases:
>>
>> Version 3.1.4
>> "PythonOption session" is not used. When calling Session.Session(req) 
>> you get the default session type for your platform: DbmSession with 
>> the prefork-mpm and worker-mpm, MemorySession with the winnt-mpm.
>>
>>
>> Version 3.2
>> "PythonOption session" was introduced to allow the default session 
>> type to be overridden at run time.
>>
>> Version 3.3 (real soon now)
>> We started using PythonOption much more heavily in 3.2 to control the 
>> run time configuration of mod_python. It quickly became apparent that 
>> the potential for key conflicts with user code was rather high, so for 
>> 3.3 we adopted a new PythonOption namespace. Thus "PythonOption 
>> session" has been deprecated in favour of "PythonOption           
>> mod_python.session.session_type".
>>
>> So my question is "How do we handle this in general?". At the very 
>> least any of the Wiki authors should note which version of mod_python 
>> they used when creating their examples.
>>
>> Jim
>>
> Jim,
>    I honestly didn't even think of this. As I started with v.3.2, my 
> example would of ended up being rather myopic in scope. My suggestion 
> for the time being is to split my page up into SubPages; one per 
> version. Adding these disclaimers (or sanitized versions that don't 
> disclose and secrets/non-finalized ideas) at the top will help alot. 
> Since I don't have any examples from 3.1.4 or 3.3, I will put a call out 
> to the list and see if anyone is willing to post some small examples.

I wouldn't create separate pages just yet. My guess is that your actual 
code will be compatible across versions 3.1 to 3.3 as the session api 
has not changed so your usage will be the same. Version  >= 3.2 just 
gives some flexibility in the session configuration through a bunch of 
PythonOptions.

I think Graham's suggestion is best - avoid the problem all together by 
not using "PythonOption session" in your configuration. :) On the other 
hand being able to set the session timeout and some other options in the 
apache configuration is pretty handy so you might want to mention them. 
I've appended the relevant 3.3 PythonOptions to bottom of the this email 
for your reference.

Also, I wouldn't worry too much about 3.1.4 support. It's getting pretty 
long in the tooth.

>    As for how to deal with this issue at the wiki-wide level,  I am very 
> hesitant to promote a required style guide on pages that discuss topics 
> that vary across releases. Those looking to post a quick nugget of 
> valuable info won't if the process requires too much effort. It may well 
> suffice by having a minimal requirement that posters say upfront what 
> version(s) their examples/info is valid for.

Some sort of detailed style guide is likely not realistic, but I suspect 
if new authors always see the same sort of boiler plate at the beginning 
of each example they'll take the hint. Something simple like "Works with 
version 3.x.x" may be sufficient. If someone comes along and tries it 
with a different version it'll be easy enough for them to amend that to 
"Works with version 3.1, 3.2".

Jim

Version 3.3 PythonOption reserved keywords
------------------------------------------
mod_python.legacy.importer * - Enables the obsolete importer.
mod_python.mutex_directory 		
mod_python.mutex_locks 		
mod_python.psp.cache_database_filename 		
mod_python.session.session_type 		
mod_python.session.cookie_name 		
mod_python.session.application_domain 		
mod_python.session.application_path 		
mod_python.session.database_directory 		
mod_python.dbm_session.database_filename 		
mod_python.dbm_session.database_directory 		
mod_python.file_session.enable_fast_cleanup 		
mod_python.file_session.verify_session_timeout 		
mod_python.file_session.cleanup_grace_period 		
mod_python.file_session.cleanup_time_limit 		
mod_python.file_session.database_directory 		

session - Deprecated, use mod_python.session.session_type

ApplicationPath -Deprecated, use mod_python.session.application_path

session_cookie_name - Deprecated, use mod_python.session.cookie_name

session_directory - Deprecated, use mod_python.session.session_directory

session_dbm - Deprecated, use mod_python.dbm_session.database_filename

session_cleanup_time_limit - Deprecated, use 
mod_python.file_session.cleanup_time_limit

session_fast_cleanup - Deprecated, use 
mod_python.file_session.enable_fast_cleanup

session_grace_period - Deprecated, use 
mod_python.file_session.cleanup_grace_period

session_verify_cleanup 	- Deprecated, use 
mod_python.file_session.cleanup_session_timeout

PSPDbmCache - Deprecated, use mod_python.psp.cache_database_filename

Mime
View raw message