Re: updating r->finfo on $r->filename($newfile)

Geoffrey Young wrote:
> > > 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:stas@xxxxxxxxxx http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com