This seems like a good plan. I'll make the changes to the code and docs
- I don't want you to do all the work Graham. ;)
Jim
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12376137 ]
Graham Dumpleton commented on MODPYTHON-127:
--------------------------------------------
Okay, lets not use camel case and where a sub namespace is required, it should
refer to the concept of what is being implemented as opposed to a specific
class name. Thus two general forms would be:
mod_python.global_option_name
mod_python.feature_name.sub_option_name
Thus:
psp.py
# class PSP
PSPDbmCache ==> mod_python.psp.cache_database_filename
Session.py
# class BaseSession
session_cookie_name ==> mod_python.session.cookie_name
ApplicationPath ==> mod_python.session.application_path
# class DbmSession
session_dbm ==> mod_python.dbm_session.database_filename
session_directory ==> mod_python.dbm_session.database_directory
# class FileSession
session_fast_cleanup ==> mod_python.file_session.enable_fast_cleanup
session_verify_cleanup ==> mod_python.file_session.verify_session_timeout
session_grace_period ==> mod_python.file_session.cleanup_grace_period
session_cleanup_time_limit ==> mod_python.file_session.cleanup_time_limit
session_directory ==> mod_python.file_session.database_directory
# class Session
session ==> mod_python.session.session_type
Documentation would state that any option of form mod_python.* is reserved for
mod_python use. Documentation should also encourage users when creating add-ons
to use their own namespace qualifier and not pollute the global namespace.
In respect of backward compatibility for old option names, although it would be
logical to support old names, I would suggest we add an option:
mod_python.allow_old_option_names
For now this would default to "1" indicating that old names would still be supported. It
could though be used to turn off acceptance of old names. Come the next major version, I would
suggest the default for this option change to "0" indicating that by default old names
would not be accepted. At that time if you really need to use the old names, then you can enable
the support.
Use namespace for mod_python PythonOption settings.
---------------------------------------------------
Key: MODPYTHON-127
URL: http://issues.apache.org/jira/browse/MODPYTHON-127
Project: mod_python
Type: Improvement
Components: core
Versions: 3.3
Reporter: Graham Dumpleton
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/mod_python/2006-February/020213.html
