[jira] Commented: (MODPYTHON-128) Have assigning req.filename automatically update req.finfo.

["Graham Dumpleton (JIRA)" <ji...@apache.org>]

    [ 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