|
Home > Archive > Apache Mod-Python > August 2006 > Updated: (MODPYTHON-127) Use namespace for mod_python
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Updated: (MODPYTHON-127) Use namespace for mod_python
|
|
| Graham Dumpleton (JIRA) 2006-08-13, 7:12 am |
| [ http://issues.apache.org/jira/brows...ON-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/...ary/020213.html
| |
| Jim Gallacher 2006-08-13, 1:12 pm |
| Graham Dumpleton (JIRA) wrote:
> [ http://issues.apache.org/jira/brows...ON-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 warni
ng 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}
| |
| Jim Gallacher 2006-08-15, 1:12 pm |
| Graham Dumpleton wrote:
>
> On 14/08/2006, at 1:42 AM, Jim Gallacher wrote:
>
> 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
|
|
|
|
|