You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/02/09 23:31:55 UTC
[jira] Created: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
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] Work started: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=all ]
Work on MODPYTHON-127 started by Graham Dumpleton.
> 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
[jira] Commented: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Jim Gallacher (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12441188 ]
Jim Gallacher commented on MODPYTHON-127:
-----------------------------------------
+1
Your suggestion is logical. Explicit is better than implict.
> 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
[jira] Commented: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Jim Gallacher (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12372284 ]
Jim Gallacher commented on MODPYTHON-127:
-----------------------------------------
I've scanned the source and I think you have caught all the instances that need changing.
Are we sure we want to use CamelCase in the option names? I think this may be confusing if there is not a 1:1 correspondence between the PythonOption key and actual module namespace. So should it be
mod_python.FileSession.some_option
or
mod_python.session.FileSession.some_option?
I'd rather not use CamelCase if we don't have a 1:1 mapping between the PythonOption key and the fully qualified class name. So either use
mod_python.file_session.fast_cleanup
or
mod_python.session.FileSession.fast_cleanup
I'd avoid using mod_python.BaseSession, and just use mod_python.session for global session options. Using BaseSession just exposes an implementation detail and does not make the intent any clearer. Plus
Again, notice the potential confusion with the camel case. session.Session is a factory function, so should mod_python.Session.some_option only control the behaviour of that function, or is it intended as global option for all session classes? What if a user creates a session instance directly, bypassing session.Session() - should mod_python.Session.some_option still be used?
I think for your proposed changes for the FileSession options are logical and should be adopted. I wonder though if we should refactor the constructor to use the new names as well? It would certainly be easier to do this now as FileSession may not be widely adopted yet. Consistency is a good thing after all.
There is no conflict using session_directory for both DbmSession and FileSession. DbmSession creates a dbm file (/session/directory/mp_sess.dbm) in the directory, while FileSession creates its file hiearchy its own subdirectory (/session/directory/mp_sess/). Of course people are free to use mod_python.DbmSession.database_filename /session/directory/mp_sess to mess things up, but there is not much we can do about that.
My original thinking was that the session directory would be global to any session class that needs it. Should that directory flip back to the default (/tmp) just because I decide to use a different session class? Of course we could have it both ways:
if 'mod_python.session.FileSession.database_directory' in options
use it
else
use mod_python.session.database_directory
> 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] Assigned: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=all ]
Graham Dumpleton reassigned MODPYTHON-127:
------------------------------------------
Assignee: Graham Dumpleton
> 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
[jira] Commented: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Jim Gallacher (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12443889 ]
Jim Gallacher commented on MODPYTHON-127:
-----------------------------------------
We need to make sure we address this in the unittests as well. Should we have tests for the additional options?
> 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.
Posted by Jim Gallacher <jp...@jgassociates.ca>.
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.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ 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.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ 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
[jira] Closed: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Graham Dumpleton closed MODPYTHON-127.
--------------------------------------
> Use namespace for mod_python PythonOption settings.
> ---------------------------------------------------
>
> Key: MODPYTHON-127
> URL: https://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.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Graham Dumpleton (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/MODPYTHON-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.
I'll have some time this weekend to audit the code.
Jim
[jira] Resolved: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-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/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] Updated: (MODPYTHON-127) Use namespace for mod_python PythonOption settings.
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 14/08/2006, at 1:42 AM, Jim Gallacher wrote:
> Graham Dumpleton (JIRA) wrote:
>> [ http://issues.apache.org/jira/browse/MODPYTHON-127?page=all ]
>>
>> Graham Dumpleton updated MODPYTHON-127:
>> ---------------------------------------
>>
>> Fix Version/s: 3.3
>>
>> Lets target this to be done for 3.3. We just need some agreement
>> that proposed names are okay, plus a consensus on how we go about
>> deprecating old names. Do we have an option now which if enabled
>> prohibits use of old names and outputs some sort of warning if
>> they are, or do we do something else?
>>
>
> Forgive the LaTex. Here is a list that I had started to compile. We'll
> need to audit the affected bits of code to make sure they are actually
> using the new namespace. I haven't given any thought to the
> deprecation
> process though.
>
> Jim
>
> ----------------------------------------------------------------------
> --
> \strong{Reserved PythonOption Keywords}
>
> Some PythonOption keywords are used for configuring various aspects of
> mod_python. Any keyword starting with mod_python.* should be
> considered
> as reserved for internal mod_python use.
>
> Users are encouraged to use their own namespace qualifiers when
> creating
> add-on modules, and not pollute the global namespace.
>
> The following PythonOption keys are currently used by mod_python.
>
> % Note - Make sure you put a space character in any empty tables
> cells.
> % Otherwise the formatting will be messed up.
> \begin{tableiii}{l|c|l}{textrm}{Key}{Required Value}{Notes}
> \lineiii{mod_python.future.importer}{*}{Enables the experimental
> module importer.}
> \lineiii{mod_python.mutex_directory}{ }{ }
> \lineiii{mod_python.mutex_locks}{ }{ }
> \lineiii{mod_python.psp.cache_database_filename}{ }{ }
> \lineiii{mod_python.session.session.session_type}{ }{ }
Presume you meant:
\lineiii{mod_python.session.session_type}{ }{ }
Anyway, am going to start making the changes to the code.
Will support both old and new option names and unless I am
inspired will not do anything about deprecation warnings in
this version.
> \lineiii{mod_python.session.cookie_name}{ }{ }
> \lineiii{mod_python.session.application_path}{ }{ }
> \lineiii{mod_python.dbm_session.database_filename}{ }{ }
> \lineiii{mod_python.file_session.enable_fast_cleanup}{ }{ }
> \lineiii{mod_python.file_session.verify_session_timeout}{ }{ }
> \lineiii{mod_python.file_session.cleanup_grace_period}{ }{ }
> \lineiii{mod_python.file_session.cleanup_time_limit}{ }{ }
>
> \lineiii{session}{ }{Deprecated, use
> mod_python.session.session_type}
> \lineiii{session_directory}{ }{Deprecated, use
> mod_python.session.session_directory}
> \lineiii{session_fast_cleanup}{ }{Deprecated, use
> mod_python.file_session.enable_fast_cleanup}
> \lineiii{session_grace_period}{ }{Deprecated, use
> mod_python.file_session.cleanup_grace_period}
> \lineiii{session_verify_cleanup}{ }{Deprecated, use
> mod_python.file_session.cleanup_session_timeout}
> \lineiii{mod_python.}{ }{ }
> \end{tableiii}
>
Re: [jira] Updated: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Graham Dumpleton wrote:
>
> On 14/08/2006, at 1:42 AM, Jim Gallacher wrote:
>>> Lets target this to be done for 3.3. We just need some agreement that
>>> proposed names are okay, plus a consensus on how we go about
>>> deprecating old names. Do we have an option now which if enabled
>>> prohibits use of old names and outputs some sort of warning if they
>>> are, or do we do something else?
>>>
>>
>> Forgive the LaTex. Here is a list that I had started to compile. We'll
>> need to audit the affected bits of code to make sure they are actually
>> using the new namespace. I haven't given any thought to the deprecation
>> process though.
>
> How about in 3.3 we support new and old names and in 4.0 when old
> importer is done away with, we also do away with old names. In other
> words, 4.0 becomes where we stop supporting anything we are
> deprecating. Can do the same thing with server cleanup functions.
> Stub them in 3.3 and remove them in 4.0.
Sounds like a good plan.
Jim
Re: [jira] Updated: (MODPYTHON-127) Use namespace for mod_python PythonOption settings.
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 14/08/2006, at 1:42 AM, Jim Gallacher wrote:
>> Lets target this to be done for 3.3. We just need some agreement
>> that proposed names are okay, plus a consensus on how we go about
>> deprecating old names. Do we have an option now which if enabled
>> prohibits use of old names and outputs some sort of warning if
>> they are, or do we do something else?
>>
>
> Forgive the LaTex. Here is a list that I had started to compile. We'll
> need to audit the affected bits of code to make sure they are actually
> using the new namespace. I haven't given any thought to the
> deprecation
> process though.
How about in 3.3 we support new and old names and in 4.0 when old
importer is done away with, we also do away with old names. In other
words, 4.0 becomes where we stop supporting anything we are
deprecating. Can do the same thing with server cleanup functions.
Stub them in 3.3 and remove them in 4.0.
Graham
Re: [jira] Updated: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Graham Dumpleton (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/MODPYTHON-127?page=all ]
>
> Graham Dumpleton updated MODPYTHON-127:
> ---------------------------------------
>
> Fix Version/s: 3.3
>
> Lets target this to be done for 3.3. We just need some agreement that proposed names are okay, plus a consensus on how we go about deprecating old names. Do we have an option now which if enabled prohibits use of old names and outputs some sort of warning if they are, or do we do something else?
>
Forgive the LaTex. Here is a list that I had started to compile. We'll
need to audit the affected bits of code to make sure they are actually
using the new namespace. I haven't given any thought to the deprecation
process though.
Jim
------------------------------------------------------------------------
\strong{Reserved PythonOption Keywords}
Some PythonOption keywords are used for configuring various aspects of
mod_python. Any keyword starting with mod_python.* should be considered
as reserved for internal mod_python use.
Users are encouraged to use their own namespace qualifiers when creating
add-on modules, and not pollute the global namespace.
The following PythonOption keys are currently used by mod_python.
% Note - Make sure you put a space character in any empty tables cells.
% Otherwise the formatting will be messed up.
\begin{tableiii}{l|c|l}{textrm}{Key}{Required Value}{Notes}
\lineiii{mod_python.future.importer}{*}{Enables the experimental
module importer.}
\lineiii{mod_python.mutex_directory}{ }{ }
\lineiii{mod_python.mutex_locks}{ }{ }
\lineiii{mod_python.psp.cache_database_filename}{ }{ }
\lineiii{mod_python.session.session.session_type}{ }{ }
\lineiii{mod_python.session.cookie_name}{ }{ }
\lineiii{mod_python.session.application_path}{ }{ }
\lineiii{mod_python.dbm_session.database_filename}{ }{ }
\lineiii{mod_python.file_session.enable_fast_cleanup}{ }{ }
\lineiii{mod_python.file_session.verify_session_timeout}{ }{ }
\lineiii{mod_python.file_session.cleanup_grace_period}{ }{ }
\lineiii{mod_python.file_session.cleanup_time_limit}{ }{ }
\lineiii{session}{ }{Deprecated, use mod_python.session.session_type}
\lineiii{session_directory}{ }{Deprecated, use
mod_python.session.session_directory}
\lineiii{session_fast_cleanup}{ }{Deprecated, use
mod_python.file_session.enable_fast_cleanup}
\lineiii{session_grace_period}{ }{Deprecated, use
mod_python.file_session.cleanup_grace_period}
\lineiii{session_verify_cleanup}{ }{Deprecated, use
mod_python.file_session.cleanup_session_timeout}
\lineiii{mod_python.}{ }{ }
\end{tableiii}
[jira] Updated: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=all ]
Graham Dumpleton updated MODPYTHON-127:
---------------------------------------
Fix Version/s: 3.3
Lets target this to be done for 3.3. We just need some agreement that proposed names are okay, plus a consensus on how we go about deprecating old names. Do we have an option now which if enabled prohibits use of old names and outputs some sort of warning if they are, or do we do something else?
> 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
> 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
[jira] Commented: (MODPYTHON-127) Use namespace for mod_python
PythonOption settings.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ 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