You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Havard <br...@kheldar.apana.org.au> on 1999/05/12 17:14:13 UTC
APR: directory API
Now that the dust has settled (I hope) over the ap/apr argument I'd like to
bring up the problem I still have with the directory API.
The problem is that ap_readdir() still returns a dirent *. It may be hidden
under several layers of typedef but that's still what it is and still has to
be treated as such by the API user. IE you have to access the file name as
ent->d_name. The test program even uses d_ino which is far from portable.
I presented what I think is a better solution a while back in message
<19...@silk.apana.org.au> and I'd be happy to implement it
for the platforms I have access to (OS/2, Unix and Win32) if it's generally
approved of. Not only is it fully platform independent but provides more
possibilities for exploiting the features of of each platform. I also think
it's cleaner in that there's only one data structure for the user to keep
track of instead of two.
It looked something like this:
apr_dir_t *apr_opendir(const char *);
apr_status_t apr_closedir(apr_dir_t *);
apr_status_t apr_readdir(apr_dir_t *);
apr_ssize_t apr_dir_entry_size(apr_dir_t *);
apr_time_t apr_dir_entry_mtime(apr_dir_t *);
apr_status_t apr_rewinddir(apr_dir_t *);
Note no apr_dirent_t at all. It would be use like:
thisdir = apr_opendir("foo/bar");
if (thisdir) {
while(apr_readdir(thisdir) == APR_SUCCESS) {
printf("%s %d\n", thisdir->entryname, apr_dir_entry_size(thisdir));
}
}
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: Apache port to PVM(BeoWulf Clusters)?
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Papageorio,
Having worked some with PVM in the past, I am curious how you see
Apache benefiting from a PVM "port"?
It is my understanding that PVM provides an underlying communications
API that allows for "seamless" distribution of manually architected
components. This provides a portable communications/distribution layer,
but does not address other portability issues such as memory, file I/O,
and mutex support.
There are many applications that benefit (or would benefit) from PVM.
Other than getting load balancing for free what benefits do you see for
Apache? Keep in mind that there is currently work being done to port
Apache to use a portable runtime API set that addresses all of the
portability issues, and that (as you pointed out) Apache can already
be clustered.
Those questions aside, I would certainly be curious about a port from
a purely theoretical standpoint and might even be interested in playing
with it some (but after my current thesis research is done). I am
personally very interested in the Beowulf architecture.
-------------------------------------------------
papageorgio wrote:
> This post concerns the desire of a small group to port Apache to
> PVM (Boewulf clustering API), and whether or not there is a need
> or want for such a port.
>
> First off I will outline this long and winding post. This way if
> you are not to interested, you can skip to this or that then move
> on.
>
> I. Who are we?
> II. What is pvm?
> III. What can be achieved by a port to pvm?
> 1. Apache would be instantly ported new platforms.
> 2. advanced load balancing.
> 3. higher degree of clustering configuration options.
> 4. PVM is an API not an OS.
> IV. Things to consider that may not make it worth a port.
> 1. Apache can already be clustered.
> 2. Many of the new platforms do not have a big need for Apache.
> 3. PVM offers no increase in speed.
> 4. The level of complexity would increase.
> V. What do you think?
>
> Note: I have tried to make this as short as possible, so many things
> were left out (Like Detail), however if there is an interested in this
> then we can clarify, research and discuss it in detail.
>
> I.Who are we?
>
> We are a small group of developers and demented linux users with our own
> cluster (www.netttrash.com/users/thepile).
>
> II. What is pvm?
>
> PVM is one of massage passing API's used to form Beowulf clusters. It
> allows several heterogeneous computers to be networked together in order
> to use the sum of there hardware to create the allusion of a single a
> parallel processing computer.
>
> III. What can be achieved by a port to pvm?
>
> 1. Apache would be instantly ported new platforms.
>
> PVM has been ported to all kinds of platforms and by porting
> Apache to PVM, Apache would be simultaneously ported to those
> platforms. For information see www.epm.ornl.gov/pvm/pvmArch.html
>
> 2. advanced load balancing.
>
> Porting Apache to PVM would give it advanced load balancing
> capabilities, PVM monitors and adjusts automatically tasks per
> machine. Distribution can also be manually set, from the process
> level to the cluster overall.
>
> 3. a higher degree of clustering configuration options.
>
> PVM has an infinite number of ways it can be clustered. Since PVM
> sits ontop of the OS it is only limited by the OS's network
> capabilities.
>
> 4. PVM is an API not an OS.
>
> PVM is not tied to an OS or a kernel. So as OS's evolve most changes
> will effect PVM not Apache.
>
> IV. Things to consider that may not make it worth a port.
>
> 1. apache can already be clustered.
>
> 2. Many of the PVM platforms do not have a big need for apache.
>
> granted a cluster of Cray2s running apache would be cool.
>
> 3. PVM offers no increase in speed.
>
> PVM would not offer an increase in tasks completed per computer, but it
> would be comparible to a round robin cluster using software routing.
>
> 4. The level of complexity would increase.
>
> Since the BeoWulf clusters design is only limited by your imagination,
> fine tuning would be just short of organizing cats into marching lines.
>
> V.What do you think?
>
> Is this a bad idea that would amount to nothing more than a waste of
> time?
> Is this a good idea that would amount to nothing more than a waste of
> time?
> It is interesting but more information is needed to comment.
> Yah this is good idea and it could be used.
>
> papageorgio
--
Paul J. Reder
--------- from Red Hat Linux fortunes -----------------------------
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental. Any
resemblance between the above and my own views is non-deterministic. The
question of the existence of views in the absence of anyone to hold them
is left as an exercise for the reader. The question of the existence of
the reader is left as an exercise for the second god coefficient. (A
discussion of non-orthogonal, non-integral polytheism is beyond the scope
of this article.)
Re: Apache port to PVM(BeoWulf Clusters)?
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 12 May 1999, papageorgio wrote:
> V.What do you think?
>
> Is this a bad idea that would amount to nothing more than a waste of
> time?
> Is this a good idea that would amount to nothing more than a waste of
> time?
> It is interesting but more information is needed to comment.
> Yah this is good idea and it could be used.
Well, for the server as shipped I really don't see how this gains
anything... there's already easy ways to distribute the load around a
cluster. But if the user has some module that can make good use of PVM...
well... that's another story.
Don't let my comments stop you from having fun though :)
Dean
Apache port to PVM(BeoWulf Clusters)?
Posted by papageorgio <pa...@efortress.com>.
This post concerns the desire of a small group to port Apache to
PVM (Boewulf clustering API), and whether or not there is a need
or want for such a port.
First off I will outline this long and winding post. This way if
you are not to interested, you can skip to this or that then move
on.
I. Who are we?
II. What is pvm?
III. What can be achieved by a port to pvm?
1. Apache would be instantly ported new platforms.
2. advanced load balancing.
3. higher degree of clustering configuration options.
4. PVM is an API not an OS.
IV. Things to consider that may not make it worth a port.
1. Apache can already be clustered.
2. Many of the new platforms do not have a big need for Apache.
3. PVM offers no increase in speed.
4. The level of complexity would increase.
V. What do you think?
Note: I have tried to make this as short as possible, so many things
were left out (Like Detail), however if there is an interested in this
then we can clarify, research and discuss it in detail.
I.Who are we?
We are a small group of developers and demented linux users with our own
cluster (www.netttrash.com/users/thepile).
II. What is pvm?
PVM is one of massage passing API's used to form Beowulf clusters. It
allows several heterogeneous computers to be networked together in order
to use the sum of there hardware to create the allusion of a single a
parallel processing computer.
III. What can be achieved by a port to pvm?
1. Apache would be instantly ported new platforms.
PVM has been ported to all kinds of platforms and by porting
Apache to PVM, Apache would be simultaneously ported to those
platforms. For information see www.epm.ornl.gov/pvm/pvmArch.html
2. advanced load balancing.
Porting Apache to PVM would give it advanced load balancing
capabilities, PVM monitors and adjusts automatically tasks per
machine. Distribution can also be manually set, from the process
level to the cluster overall.
3. a higher degree of clustering configuration options.
PVM has an infinite number of ways it can be clustered. Since PVM
sits ontop of the OS it is only limited by the OS's network
capabilities.
4. PVM is an API not an OS.
PVM is not tied to an OS or a kernel. So as OS's evolve most changes
will effect PVM not Apache.
IV. Things to consider that may not make it worth a port.
1. apache can already be clustered.
2. Many of the PVM platforms do not have a big need for apache.
granted a cluster of Cray2s running apache would be cool.
3. PVM offers no increase in speed.
PVM would not offer an increase in tasks completed per computer, but it
would be comparible to a round robin cluster using software routing.
4. The level of complexity would increase.
Since the BeoWulf clusters design is only limited by your imagination,
fine tuning would be just short of organizing cats into marching lines.
V.What do you think?
Is this a bad idea that would amount to nothing more than a waste of
time?
Is this a good idea that would amount to nothing more than a waste of
time?
It is interesting but more information is needed to comment.
Yah this is good idea and it could be used.
papageorgio
Re: APR: directory API
Posted by Ben Hyde <bh...@pobox.com>.
Dean's comments got be thinking, let me throw some ideas in the pot.
I've not looked at the current proposal very carefully.
A bit field to denote "data desired" in the open generator call can
be very useful when you trying to get some uniformity across platforms.
Then the platform specific call can pick the OS call pattern that's
cheapest given the request being made.
ap_file_list *fi = ap_file_list_create(p, pattern, APDI_MOD_TIME|APDI_SIZE|APDI_RECURSE)
...
while(ap_file_list_advance(fi)){
if( intersting(ap_file_iterator(fi)) ){
ap_rprintf(r, "<td>%s</td><td>%d</td>",
ap_file_name(fi),
ap_file_size(fi));
}
}
...
The doc should say it is an error to call ap_file and it's ilk
prior to the first advance, or after advance returns non-nil,
otherwise ap_file_name et. al never generate errors.
You can get much the same effect by having N different create iterator
operations.
We did discuss at one time using file:/... URL's for this kind of thing.
That folds into the issue of how low in the archetecture we should
start using uri_components and the other stuff currently in util_uri.
There was a time when I thought that would be an important data
structure, but these days it seems almost unnecessary.
If what this generator generates is uri_components then one would
put fields in there for various dates, sizes, mime types, along
with a bit field to indicate where ones held valid data.
- ben
Re: APR: directory API
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Okay, maybe I was a bit too strong with my comments. On systems where it
is impossible to do something, there will NEED to be some feature macros.
When they are necessary of course they will be provided. This is what we
will be doing for ap_fork.
However, when it is possible to do something on a system, I want to
provide that function. Most unixes provide more information than the
posix standard provides, so there will be no need to do a stat for some of
those functions.
As I said both in the commit and te last message, I am getting to it. The
first pass for APR is a completely posix compliant layer. This is
easiest, it doesn't require any #ifdefs, and it is garaunteed to work.
When I am done with the first round (RSN), I can start to improve it
slowly. I really want to get something that Apache can use as soon as it
is ready. That is my first priority right now.
I will define macros for systems that do things in stupid ways, so users
can do the same thing in other ways, but I will also provide all the
features I can for ALL platforms.
Ryan
On Sat, 15 May 1999, Dean Gaudet wrote:
>
>
> On Sat, 15 May 1999, Ryan Bloom wrote:
>
> >
> > Doesn't this break the whole idea of a PORTABLE run-time?
>
> Dude, feature macros are exactly what we could use to decide on how to
> architect the server. This fancy architecture we're talking about is a
> unix only solution, and even on unix we're going to need variants. We're
> going to do something completely different on NT.
>
> It doesn't matter how abstract your portable runtime is, there are times
> when you just plain "can't get there from here". And this is one of them.
> If for some reason I can do something intelligent on a system without
> mtime in the opendir/readdir which avoids the stat(), then I want to do
> it. And the best way for me to know to do that is to have a feature
> macro.
>
> > I thought the
> > goal was to allow somebody to write code on one system and run it just
> > about anywhere. There are definite improvements to the code I committed.
> > I'll get to them. Having feature only macros puts the responsibility for
> > porting code on the programer instead of on apr.
>
> Do it as an option then, I don't care if the mtime stuff is available when
> the feature macro isn't set, as long as I can write code that's
> intelligent when the runtime has to simulate something.
>
> > We can define those macros for programmers who want to get better
> > performance out of different systems, but I hesitate to provide an API
> > that is only available on a subset of the platforms apr supports. The
> > ONLY API currently in APR that is not cross-platform is apr_fork, and that
> > is only there because Apache requires it, and it is un-reproducable on
> > Windows.
>
> Uh, then you and me are going to be at odds for a lot of things.
>
> Tell me how you're going to put symlink support into APR for example.
> Keep in mind that NT5.0 support something like symlinks, but NT4.0
> doesn't. If we don't abstract it we'll have NT5.0 specific code and unix
> specific code in the core... doing pretty much the same thing. But if we
> do abstract it, we can put a simple conditional #ifdef AP_HAS_SYMLINKS in
> the core.
>
> And perhaps the most obvious: how are we going to do pathname parsing?
> We need HAS_DRIVE_LETTERS or something like it. That's a feature macro.
>
> One of the examples where NSPR could use a feature macro is
> PR_NewTCPSocketPair -- this does a socketpair() and wraps the results in
> NSPR filehandles. There's no way to convert a unix fd to a NSPR file
> handle in NSPR... this is deliberate, because it breaks all the
> abstractions. But at the same time, it sucks not being able to use
> socketpair()s in some cases (can tune their size, can use them in datagram
> mode)... In some sense you could call PR_NewTCPSocketPair at run time and
> get back a "not implemented" error... but what a waste of code...
>
> Dean
>
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: APR: directory API
Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 15 May 1999, Ryan Bloom wrote:
>
> Doesn't this break the whole idea of a PORTABLE run-time?
Dude, feature macros are exactly what we could use to decide on how to
architect the server. This fancy architecture we're talking about is a
unix only solution, and even on unix we're going to need variants. We're
going to do something completely different on NT.
It doesn't matter how abstract your portable runtime is, there are times
when you just plain "can't get there from here". And this is one of them.
If for some reason I can do something intelligent on a system without
mtime in the opendir/readdir which avoids the stat(), then I want to do
it. And the best way for me to know to do that is to have a feature
macro.
> I thought the
> goal was to allow somebody to write code on one system and run it just
> about anywhere. There are definite improvements to the code I committed.
> I'll get to them. Having feature only macros puts the responsibility for
> porting code on the programer instead of on apr.
Do it as an option then, I don't care if the mtime stuff is available when
the feature macro isn't set, as long as I can write code that's
intelligent when the runtime has to simulate something.
> We can define those macros for programmers who want to get better
> performance out of different systems, but I hesitate to provide an API
> that is only available on a subset of the platforms apr supports. The
> ONLY API currently in APR that is not cross-platform is apr_fork, and that
> is only there because Apache requires it, and it is un-reproducable on
> Windows.
Uh, then you and me are going to be at odds for a lot of things.
Tell me how you're going to put symlink support into APR for example.
Keep in mind that NT5.0 support something like symlinks, but NT4.0
doesn't. If we don't abstract it we'll have NT5.0 specific code and unix
specific code in the core... doing pretty much the same thing. But if we
do abstract it, we can put a simple conditional #ifdef AP_HAS_SYMLINKS in
the core.
And perhaps the most obvious: how are we going to do pathname parsing?
We need HAS_DRIVE_LETTERS or something like it. That's a feature macro.
One of the examples where NSPR could use a feature macro is
PR_NewTCPSocketPair -- this does a socketpair() and wraps the results in
NSPR filehandles. There's no way to convert a unix fd to a NSPR file
handle in NSPR... this is deliberate, because it breaks all the
abstractions. But at the same time, it sucks not being able to use
socketpair()s in some cases (can tune their size, can use them in datagram
mode)... In some sense you could call PR_NewTCPSocketPair at run time and
get back a "not implemented" error... but what a waste of code...
Dean
Re: APR: directory API
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Doesn't this break the whole idea of a PORTABLE run-time? I thought the
goal was to allow somebody to write code on one system and run it just
about anywhere. There are definite improvements to the code I committed.
I'll get to them. Having feature only macros puts the responsibility for
porting code on the programer instead of on apr.
We can define those macros for programmers who want to get better
performance out of different systems, but I hesitate to provide an API
that is only available on a subset of the platforms apr supports. The
ONLY API currently in APR that is not cross-platform is apr_fork, and that
is only there because Apache requires it, and it is un-reproducable on
Windows.
Ryan
On Fri, 14 May 1999, Dean Gaudet wrote:
> BTW, I was thinking more about the extras which OS/2 and windows
> provide... those really should be available under feature macros only --
>
> #ifdef AP_HAS_DIR_MTIME
> ...
> #endif
>
> Because someone may want to do things entirely differently when there's no
> native mtime in the opendir/readdir API.
>
> Dean
>
> On Thu, 13 May 1999, Ryan Bloom wrote:
>
> >
> > Just thought I would let everybody know that the dir stuff has changed
> > again. :)
> >
> > I just committed the new directory stuff for Unix. These are not
> > optimized at all! I purposefully made these completely POSIX compliant.
> > If anybody wants to go in a make these perform MUCH better for specific
> > Unix's, then be my guest. If nobody else gets to it, I'll do it when the
> > rest of APR is finished.
> >
> > Ryan
> >
> > On Wed, 12 May 1999, Ryan Bloom wrote:
> >
> > > > > When the user does an ap_opendir, does that get the first entry in the
> > > > > directory. I think it should personnaly, unless somebody can provide a
> > > > > good reason why it shouldn't.
> > > >
> > > > It shouldn't because then you can't report errors which occur while
> > > > reading separately from errors of opening... read() isn't part of open().
> > >
> > > I'll go along with that, but we could just use a different value for errno
> > > for the two different stages. I think you are right though. First open,
> > > then read.
> > >
> > > >
> > > > Oh, btw, NT and OS/2 also support wildcards in their equiv of "opendir()"
> > > > ...
> > >
> > > I would suggest we not support wildcards in the first release. It
> > > wouldn't mean any code to check for wildcards, just don't advertise that
> > > they are allowed on NT/OS2. If we decide we like them, we can implement
> > > the same feature in a later release for all other platforms.
> > >
> > > Ryan
> > > _______________________________________________________________________
> > > Ryan Bloom rbb@raleigh.ibm.com
> > > 4205 S Miami Blvd
> > > RTP, NC 27709 It's a beautiful sight to see good dancers
> > > doing simple steps. It's a painful sight to
> > > see beginners doing complicated patterns.
> > >
> >
> > _______________________________________________________________________
> > Ryan Bloom rbb@raleigh.ibm.com
> > 4205 S Miami Blvd
> > RTP, NC 27709 It's a beautiful sight to see good dancers
> > doing simple steps. It's a painful sight to
> > see beginners doing complicated patterns.
> >
> >
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: APR: directory API
Posted by Dean Gaudet <dg...@arctic.org>.
BTW, I was thinking more about the extras which OS/2 and windows
provide... those really should be available under feature macros only --
#ifdef AP_HAS_DIR_MTIME
...
#endif
Because someone may want to do things entirely differently when there's no
native mtime in the opendir/readdir API.
Dean
On Thu, 13 May 1999, Ryan Bloom wrote:
>
> Just thought I would let everybody know that the dir stuff has changed
> again. :)
>
> I just committed the new directory stuff for Unix. These are not
> optimized at all! I purposefully made these completely POSIX compliant.
> If anybody wants to go in a make these perform MUCH better for specific
> Unix's, then be my guest. If nobody else gets to it, I'll do it when the
> rest of APR is finished.
>
> Ryan
>
> On Wed, 12 May 1999, Ryan Bloom wrote:
>
> > > > When the user does an ap_opendir, does that get the first entry in the
> > > > directory. I think it should personnaly, unless somebody can provide a
> > > > good reason why it shouldn't.
> > >
> > > It shouldn't because then you can't report errors which occur while
> > > reading separately from errors of opening... read() isn't part of open().
> >
> > I'll go along with that, but we could just use a different value for errno
> > for the two different stages. I think you are right though. First open,
> > then read.
> >
> > >
> > > Oh, btw, NT and OS/2 also support wildcards in their equiv of "opendir()"
> > > ...
> >
> > I would suggest we not support wildcards in the first release. It
> > wouldn't mean any code to check for wildcards, just don't advertise that
> > they are allowed on NT/OS2. If we decide we like them, we can implement
> > the same feature in a later release for all other platforms.
> >
> > Ryan
> > _______________________________________________________________________
> > Ryan Bloom rbb@raleigh.ibm.com
> > 4205 S Miami Blvd
> > RTP, NC 27709 It's a beautiful sight to see good dancers
> > doing simple steps. It's a painful sight to
> > see beginners doing complicated patterns.
> >
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
Re: APR: directory API
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Just thought I would let everybody know that the dir stuff has changed
again. :)
I just committed the new directory stuff for Unix. These are not
optimized at all! I purposefully made these completely POSIX compliant.
If anybody wants to go in a make these perform MUCH better for specific
Unix's, then be my guest. If nobody else gets to it, I'll do it when the
rest of APR is finished.
Ryan
On Wed, 12 May 1999, Ryan Bloom wrote:
> > > When the user does an ap_opendir, does that get the first entry in the
> > > directory. I think it should personnaly, unless somebody can provide a
> > > good reason why it shouldn't.
> >
> > It shouldn't because then you can't report errors which occur while
> > reading separately from errors of opening... read() isn't part of open().
>
> I'll go along with that, but we could just use a different value for errno
> for the two different stages. I think you are right though. First open,
> then read.
>
> >
> > Oh, btw, NT and OS/2 also support wildcards in their equiv of "opendir()"
> > ...
>
> I would suggest we not support wildcards in the first release. It
> wouldn't mean any code to check for wildcards, just don't advertise that
> they are allowed on NT/OS2. If we decide we like them, we can implement
> the same feature in a later release for all other platforms.
>
> Ryan
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: APR: directory API
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > When the user does an ap_opendir, does that get the first entry in the
> > directory. I think it should personnaly, unless somebody can provide a
> > good reason why it shouldn't.
>
> It shouldn't because then you can't report errors which occur while
> reading separately from errors of opening... read() isn't part of open().
I'll go along with that, but we could just use a different value for errno
for the two different stages. I think you are right though. First open,
then read.
>
> Oh, btw, NT and OS/2 also support wildcards in their equiv of "opendir()"
> ...
I would suggest we not support wildcards in the first release. It
wouldn't mean any code to check for wildcards, just don't advertise that
they are allowed on NT/OS2. If we decide we like them, we can implement
the same feature in a later release for all other platforms.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: APR: directory API
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 12 May 1999, Ryan Bloom wrote:
> When the user does an ap_opendir, does that get the first entry in the
> directory. I think it should personnaly, unless somebody can provide a
> good reason why it shouldn't.
It shouldn't because then you can't report errors which occur while
reading separately from errors of opening... read() isn't part of open().
Oh, btw, NT and OS/2 also support wildcards in their equiv of "opendir()"
...
and for the "extra info" such as mtime, freebsd also provides a d_type,
which indicates the file type.
> I don't like the thisdir->entryname thing. I would much rather see a
> function/macro that returns the filename.
yeah I agree with Ryan.
Dean
Re: APR: directory API
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Wed, 12 May 1999 11:54:36 -0400 (EDT), Ryan Bloom wrote:
>The Q:
>When the user does an ap_opendir, does that get the first entry in the
>directory. I think it should personnaly, unless somebody can provide a
>good reason why it shouldn't.
>
>> thisdir = apr_opendir("foo/bar");
>> if (thisdir) {
>> while(apr_readdir(thisdir) == APR_SUCCESS) {
>> printf("%s %d\n", thisdir->entryname, apr_dir_entry_size(thisdir));
>> }
>> }
I agree with Dean's answer on this one.
>The Comment:
>
>I don't like the thisdir->entryname thing. I would much rather see a
>function/macro that returns the filename. If it is a function, it could
>be implemented inline, but the way this is written, it implies a field
>that not all platforms need. For example, in UNIX, I will most likely not
>put an entryname field in the apr_dir_t type. I will put an struct
>dirent* in there, and when the user wants the directory name, I will
>return dirvar->dirent->d_name.
I've no problem with it being a function/macro, I just thought the entryname
idea presented the simplest interface. The ap_readdir() code can just do
thisdir->entryname = thisdir->dirent->d_name;
before returning.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: APR: directory API
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I have no problem implementing this in UNIX. I can do it later today or
tomorrow. I have been meaning to re-visit this issue, but other things
keep getting in the way. I have one question, and one comment.
The Q:
When the user does an ap_opendir, does that get the first entry in the
directory. I think it should personnaly, unless somebody can provide a
good reason why it shouldn't.
> thisdir = apr_opendir("foo/bar");
> if (thisdir) {
> while(apr_readdir(thisdir) == APR_SUCCESS) {
> printf("%s %d\n", thisdir->entryname, apr_dir_entry_size(thisdir));
> }
> }
The Comment:
I don't like the thisdir->entryname thing. I would much rather see a
function/macro that returns the filename. If it is a function, it could
be implemented inline, but the way this is written, it implies a field
that not all platforms need. For example, in UNIX, I will most likely not
put an entryname field in the apr_dir_t type. I will put an struct
dirent* in there, and when the user wants the directory name, I will
return dirvar->dirent->d_name.
That is MHO, and I don't think I have done that for all the apr types, but
a lot of that is me being in a rush to get something so it will be ready
for when Apache needs it. I have it in my plan to go back and clean
thigns up a bit.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.