[wrowe@rowe-clan.net: RE: New directory API...]

[Greg Stein <gs...@lyra.org>]

[ I didn't see Bill resend this to the list, so I'm doing it now... ]

----- Forwarded message from "William A. Rowe, Jr." <wr...@rowe-clan.net> -----

From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject: RE: New directory API...
To: "'Greg Stein'" <gs...@lyra.org>
Date: Mon, 22 Jan 2001 08:36:02 -0600

> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, January 22, 2001 4:23 AM

> I'd say: have the user pick up the finfo->filehand if available and call
> apr_getfileinfo() for the bits they need (with a new structure).

finfo->filehand should be somewhat opaque.  Some platforms may not set it up
(if they didn't create a 'file' to access the fileinfo.)  Some platforms
(OS X) will have some other semantic.  Unix will look at finfo.

We should either implement apr_dir_fileinfo(finfo, wanted, thedir) _or_
create an apr_more_fileinfo(finfo, wanted) that can be used for incremental
info from stat/lstat/getfileinfo or readdir results.
 
> > 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.
> 
> Yup. I'd guess that most apps will simply do a stat rather than trying to
> really optimize the case. *If* optimization is important to them at that
> point in the code path, then yes: they'll compute a new wanted flag.
> Actually, it won't be too difficult:
> 
> wanted = MY_WANTED_FLAGS & ~finfo.valid;

No need - with either the apr_dir_fileinfo or apr_more_fileinfo calls.  They
would just look at .valid.
 
> > In our first bs session about the finfo idea, we kicked 
> > around the idea of -incrementally- calling apr_stat.
> 
> Shades of apr_open. I really don't think we want to try this.

Agreed - seperate function required.

> > Two choices.  apr_dir_fileinfo() which deals with it and merges them.
> > Or preallocate a buffer in the opendir of the fname length (dir name) plus
> > the length of the longest allowed filename, up to the limit of the total
> > path length.  No sense returning a name >_MAX_PATH, I already have this
> > exception in Win32 (and just skip over such bogus files.)
> 
> Third choice: let the caller deal with a concat if necessary. They can
> optimize the snot out of it, if that is important to them. 
> Other apps will simply do the apr_pstrcat() and be done with it.

We ourself need to concat -if- we actually do something with it ourselves.
(you've been arguing up till now against user's code bloat.)  The suggested
apr_dir_fileinfo() call does so, but would use stack to keep from bloating
the pool.  If you will use the stuff later, call apr_stat after concating
yourself; if you never need the full path, call apr_dir_fileinfo() (which
also skips the effort of requerying the known finfo.)  We must simply
document that apr_dir_fileinfo() -requires- the original apr_finfo_t buffer
from the apr_readdir() call.

I'm left with one question - would we rather have an incremental 
apr_more_fileinfo() that can ask "what do we have here?" and fill in 
the blanks, or a narrowly focused apr_dir_fileinfo() that handles 
that specific case?

Bill

----- End forwarded message -----

-- 
Greg Stein, http://www.lyra.org/