| Graham Dumpleton (JIRA) 2006-10-27, 7:11 am |
| [ http://issues.apache.org/jira/brows...ON-127?page=all ]
Graham Dumpleton resolved MODPYTHON-127.
----------------------------------------
Resolution: Fixed
For now I have just made the tests use the new option names. There is obviously a risk that I stuffed up the backward compatibility for old options, but hopefully not. Documentation updated where appropriate.
> Use namespace for mod_python PythonOption settings.
> ---------------------------------------------------
>
> Key: MODPYTHON-127
> URL: http://issues.apache.org/jira/browse/MODPYTHON-127
> Project: mod_python
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.3
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> In the interests of avoiding name clashes, I want to push that where mod_python uses its own PythonOption settings, that they use a namespace. For example:
> PythonOption mod_python.session_cookie_name ...
> PythonOption mod_python.ApplicationPath ...
> PythonOption mod_python.session_dbm ...
> PythonOption mod_python.session_fast_cleanup ...
> etc ....
> If appropriate for mod_python, multiple levels of naming should be used. For example, "session_fast_cleanup" is actually related to FileSession, so perhaps it should be:
> PythonOption mod_python.Session.cookie_name ...
> PythonOption mod_python.Session.application_path ...
> PythonOption mod_python.DbmSession.database ...
> PythonOption mod_python.FileSession.fast_cleanup ...
> Thus, class name is interjected as second level in name. Also would like to see final attribute name settle on lower case with underscore between distinct words.
> We can support old names in mod_python for the time being but should deprecate them.
> Any third party package developers should be strongly encouraged to also put any of their own PythonOption settings names in their own unique namespace.
> Mailing list thread where this was first proposed, and in case there were followups of interest, was:
> http://www.modpython.org/pipermail/...ary/020213.html
|