[
http://issues.apache.org/jira/browse/MODPYTHON-128?page=comments#action_12370962
]
Graham Dumpleton commented on MODPYTHON-128:
--------------------------------------------
As part of this change, a new req.filetype attribute should possibly be added.
This is necessary as req.finfo returns a tuple of attributes about the file,
but not the request_rec->finfo->filetype attribute.
Other alternative is for finfo to return a class like object that acts like a
tuple, but also allows access by name to attributes of structure. In other
words like the traditional result of the Python os.stat() function call.
To be able to meaningfully make use of the filtetype attribute, however
exposed, there needs to be Python constants for:
typedef enum {
APR_NOFILE = 0,
APR_REG,
APR_DIR,
APR_CHR,
APR_BLK,
APR_PIPE,
APR_LNK,
APR_SOCK,
APR_UNKFILE = 127
} apr_filetype_e;
Because this is an enum where literal values are not assigned to all values,
actual literal constants cannot simply be provided in Python module as no
gaurantees by ANSI C standard (I think) that successive values will be used.
Thus, would need through the mod_python._apache module to expose the actual
integer values for these enum values and these would then subsequently be set
in the mod_python.apache module.
If existing naming practice in conjunction with variables related to finfo
structure are used, the APR_ prefix would be dropped and the constants would be:
mod_python.apache.NOFILE
mod_python.apache.REG,
mod_python.apache.DIR,
mod_python.apache.CHR,
mod_python.apache.BLK,
mod_python.apache.PIPE,
mod_python.apache.LNK,
mod_python.apache.SOCK,
mod_python.apache.UNKFILE = 127
Is the use of the unprefixed names acceptable? Do we run the risk over time of
having naming collisions if we keep dropping prefixes? Should we instead from
now on always keep the prefixes? If we do that, what do we do about all the
mod_python.apache.FINFO_* constants? Do we provided prefixed versions, document
them and deprecate use of the older variants?
Overall, there are a mix of constants in the mod_python.apache module which do
an don't have prefixes. Some really core ones it would not make sense to change
to now have prefixes, but some others outside of that core could perhaps be.
For example all the URI_* constants. Even if we do not change anything, we need
to define a rule/guideline for going forwards.
> Have assigning req.filename automatically update req.finfo.
> -----------------------------------------------------------
>
> Key: MODPYTHON-128
> URL: http://issues.apache.org/jira/browse/MODPYTHON-128
> Project: mod_python
> Type: Improvement
> Components: core
> Versions: 3.3
> Reporter: Graham Dumpleton
>
> Although it is possible to assign a new value to "req.filename", it is not
> possible to update "req.finfo" based on the new filename.
> Suggest that if "req.filename" is assigned a new value, that apr_stat() be
> automatically called to update "req.finfo". Ie., internally mod_python would
> do something like:
> apr_stat(&r->finfo, r->filename, APR_FINFO_MIN, r->pool);
> I believe that mod_perl supports a similar feature, but would need to confirm
> this.
> Related to "req.filename", the "req.canonical_filename" should also be
> writable as when changing "req.filename" the latter should also by rights be
> updated as well.
--
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
