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 :)
I believe you are trying to compare beer with cranberry juice. request_rec is not used by perl, whereas perl wants finfo as returned by stat to work with.
so, I'll give it a whirl and see what I an do.
May I suggest that we discuss first what is to be done? Philippe has already spent a lot of time trying to do that...
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.
Before putting much thought to it, since we are so eager to provide 1:1 mapping of the C API, we should just provide the perl glue to the functions in the APR API plus accessors to those elements that have no functions.
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 :)
that could be an incosistency thing in apr lib. Not once someone implements a new thing or fixes a bug on one platform but won't sync other platforms because ...
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.
what it really does, is manipulating an internal Apache struct, hence I suggested to have a tracing option which will show only traces that affect Apache internal structs. e.g. tracing the mod of document_root sounds like a good example which will fit the MP_TRACE_a category
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?
More or less, yes.
__________________________________________________________________ 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]
