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...
hmm. maybe I'm just not understanding stuff.
I can see where it would be hard to make this work
my $size = -s $r->finfo
like it did in 1.0. but I don't see how this would be too hard
my $size = $r->finfo->csize
while it's not as nifty as 1.0, and it wouldn't have the cached _ filehandle, it seems that using apache's cached stat information would still be more efficient that a full call to -s $r->filename.
Of course. I didn't say not. You just won't be able to use perl's API for that, but instead using APR API, so instead of saying:
-r $r->finfo && -w _ ;
users will have to say:
$r->finfo->perms eq 'r' && $r->finfo->perms eq 'w'
or whatever the accessor API is (will be). The stat struct is cached but on the apache side.
or are we just not taking about the same thing here?
Yup, we are talking about the same thing. I just thought that you said you will try to provide the mapping (i.e. provide a function which will convert apr_finfo_t to finfo).
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.
I don't understand this. do you mean complete missing parts of APR::? I haven't looked at APR too closely, but yeah, if there are missing parts that would be a good thing to do :)
Neither I have looked, I hoped that finfo will somehow magically work in the future ;)
I guess I'm having a fairly unclear day :)
foggy ;)
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
ok, MP_TRACE_a it is, then.
actually, I kind of like it - if we use it for places where we add logic behind what would otherwise be raw ap* calls, that would be very nice to have.
cool.
cool++
--
__________________________________________________________________ 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]
