[ 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