httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: New directory API...
Date Mon, 22 Jan 2001 22:34:58 GMT

> > 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