httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: APR: directory API
Date Sun, 16 May 1999 08:18:36 GMT

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.


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

View raw message