[ 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 propos
ed 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 o
utputs 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_p
ython uses its own PythonOption settings, that they use a namespace. For exa
mple:
>     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. F
or example, "session_fast_cleanup" is actually related to FileSession, so pe
rhaps 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 t
o see final attribute name settle on lower case with underscore between dist
inct words.
> We can support old names in mod_python for the time being but should depre
cate them.
> Any third party package developers should be strongly encouraged to also p
ut any of their own PythonOption settings names in their own unique namespac
e.
> 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

[ Post a follow-up to this message ]

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 nam
es are okay, plus a consensus on how we go about deprecating old names. Do we have a
n option now which if enabled prohibits use of old names and outputs some sort of wa
rni
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 experimen
tal
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.sessi
on_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}

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]