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 thread...


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 :)

apr_finfo_t


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


Philippe has worked on it and he said that it won't work. See:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104495193904477&w=2
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.

right.


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
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to