perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: updating r->finfo on $r->filename($newfile)
Date Mon, 27 Oct 2003 22:02:34 GMT
Geoffrey Young wrote:
>> +1, but won't be better for Apache provide an API to set r->filename 
>> which will take care of updating finfo?
> yes, but you saw how quickly the thread died out when that idea was 
> introduced...

like most other threads on httdp-dev list, which were lucky at all to become a 

>> If Apache doesn't provide this API, and wants users to do that when 
>> they really want to (as it involves an overhead), perhaps we shouldn't 
>> do that as we did in mp1 but instead document that one has to update 
>> $r->finfo, if they need to and leave things 1:1 with C API.
> except there's no $r->finfo API, right?
> which brings me to my next question.  IIRC, when we last talked about 
> $r->finfo you said it wasn't likely to happen since there is no 
> apr_status_t mapping for perl's stat() (or something like that :)


> is it really impossible, or just a really complex typemap?  

Philippe has worked on it and he said that it won't work. See:
I don't know if anything has changed since then.

> I, for one, 
> miss $r->finfo activity, and would like to see _something_ in mp2.  
> maybe an API that's different from 1.0:
> use Apache::Finfo ();
> my $finfo = $r->finfo;
> $finfo->update(stat $foo);
> $mtime = (stat _)[9];
> $finfo->size(-s $bar);
> etc...

Sure, that will work. Though you can't manipulate finfo struct directly with 
perl function, which is what mp1 did. Moreover we must be careful what 
accessors are provided. e.g. struct apr_file_t *filehand; returns a 
filehandle, which is not FILE. Though it could be made suitable for 
manipulation with APR::PerlIO.

>> Another idea would be to provide a variation of filename() which will 
>> set filename and update finfo. e.g. filename_finfo()?
> maybe.  I think either the apache API (which will never come) or our own 
> access to $r->finfo is a better approach.


>> If you intend to keep these traces, they shouldn't be _o, which is 
>> used for I/O tracing.
> I kinda thought is was IO, since the new logic involves (underlying) 
> stat calls.  but ok - whatever you think is best is fine with me.

stat() != IO in a sense that you would want to use IO tracing if some data 
that you print is getting lost or corrupted. You would want to use some other 
tracing if you get the filestamp wrong, no?

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message