[jira] Commented: (MODPYTHON-127) Use namespace for mod_python PythonOption settings.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12440752 ] Graham Dumpleton commented on MODPYTHON-127: Have made code changes (not documentation), but not yet committed. Having done this, I found myself asking whether there should also be a: mod_python.session.database_directory This would be a fallback for when the 'session_database' option against a specific type of session class hasn't been set. Ie., search order would be: mod_python.dbm_session.database_directory mod_python.session.database_directory session_directory # for backward compatibility only and: mod_python.file_session.database_directory mod_python.session.database_directory session_directory # for backward compatibility only This would allow session directory to be set once regardless of what type of session class was used. At least, for those which store stuff in the file system, as MemorySession wouldn't use it. Comments??? 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/mod_python/2006-February/020213.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (MODPYTHON-127) Use namespace for mod_python PythonOption settings.
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
[jira] Commented: (MODPYTHON-127) Use namespace for mod_python PythonOption settings.
[ 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-127) Use namespace for mod_python PythonOption settings.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12372184 ] Graham Dumpleton commented on MODPYTHON-127: Here is the list of options that I can find and some suggestions as to what they be called instead. Remember that old options will be honoured for backward compatibility with threat of them later being deprecated. psp.py # class PSP PSPDbmCache == mod_python.PSP.cache_database_filename Session.py # class BaseSession session_cookie_name == mod_python.BaseSession.cookie_name ApplicationPath == mod_python.BaseSession.application_path # class DbmSession session_dbm == mod_python.DbmSession.database_filename session_directory == mod_python.DbmSession.database_directory # class FileSession session_fast_cleanup == mod_python.FileSession.enable_fast_cleanup session_verify_cleanup == mod_python.FileSession.verify_session_timeout session_grace_period == mod_python.FileSession.cleanup_grace_period session_cleanup_time_limit == mod_python.FileSession.cleanup_time_limit session_directory == mod_python.FileSession.database_directory # class Session session == mod_python.Session.session_type Anyone like to confirm that this is all and validate that names reasonable or suggest better names. My choices of names for FileSession, although they now have a name which is clearer to me, mean they diverge from what class initialiser variable names were. If all session types derive from BaseSession, should the existance of the BaseSession class be hidden and mod_python.Session.* be used instead of cases where list mod_python.BaseSession.*? Note that an interesting issue deriving from making this list is that both DbmSession and FileSession use the session_directory option at the moment. Could a conflict arise from doing this if they are both writing to the same directory? Feedback? 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
