[
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
