Stas Bekman wrote:
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...
yeah *sigh*
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.
right I remember that (though I thought there was some discussion on it too).
anyway, I can't bring myself to belive that we can map the request_rec to a class but we can't map apr_finfo_t. maybe it's my naivete speaking, though :)
so, I'll give it a whirl and see what I an do.
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.
well, maybe most of it will be read-only. then maybe we can provide access to apr_stat through a class method Apache::Finfo->stat or something. whatever the API, I'm sure it will take shape after the apr_finfo_t work.
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.
right. as I see it, the most used aspects of finfo will be the stuff we used to do in 1.0, which was mostly file tests. any goodies like an already open filehandle would be cool (though I only see Win32 populating finfo.filehand - kudos to them :)
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?
I can see both sides. given the current options, I think IO makes more sense than the others, but I really don't care. or if you think a new designation is deserved that's fine too, though I don't know what else would go there.
at any rate, I guess the decision is to hold off on this implementation and see what can be done with a direct mapping, right?
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
