httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: New directory API...
Date Mon, 22 Jan 2001 22:42:56 GMT
Bill,

  give me a quick ring, would you?  847-265-8130 - I'm wrapping and closing
the apr_dir_read patches right now.

Bill

----- Original Message ----- 
From: "Bill Stoddard" <bill@wstoddard.com>
To: <new-httpd@apache.org>
Sent: Monday, January 22, 2001 4:34 PM
Subject: Re: New directory API...


> 
> > > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > > Sent: Sunday, January 21, 2001 10:39 PM
> > >
> > > > > -apr_status_t apr_readdir(apr_dir_t *thedir)
> > > > > +apr_status_t apr_readdir(apr_finfo_t *finfo, apr_dir_t *thedir)
> > > >
> > > > The other side of the question - do we -want- the apr_readdir fn to
> > > > accept an apr_int32_t wanted arg, passed to stat or handled internally
> > > > based on the platform?  The obvious consiquence - if we pass wanted
> > > > as APR_FINFO_FNAME we get nothing but a filename (no stat req'd.)
> > > > Depending on the platform, you may have other goodies for free, or
> > > > you can request precisely what we need [this needs resolution of the
> > > > other, APR_INCOMPLETE, side of the coin.]
> > >
> > > I dislike combining the readdir and the stat call.  We can provide what
> > > comes for free, anything more should be the result of a separate stat
> > > call.
> >
> > Alrighty then... I will live with that till we are proven wrong.  I presume
> > we mean to 'reuse' the apr_finfo_t struct in the subsequent call, so we
> > need to watch for any 'oops'.  Of course, the user is left testing what
> > they 'wanted' twice, once to see if apr_readdir picked it up, and again to
> > see if apr_stat did the second time around.  Very sub-optimal.
> >
> > In our first bs session about the finfo idea, we kicked around the idea
> > of -incrementally- calling apr_stat.  I don't like the ambiguity.  This
> > is certainly the argument for it, though.  The idea is that we don't want
> > to call stat for something stat will refuse to provide, but we need to
> > tell stat that we have 'really good stuff here', and not to worry about
> > giving us what we already know.  Perhaps an APR_FINFO_INCREMENTAL flag
> > or some such.
> 
> 
> Please no.  I hate hyper-specialized APIs...
> 
> Bill
> 
> 


Mime
View raw message