httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: APR: directory API
Date Sun, 16 May 1999 02:38:38 GMT


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



Mime
View raw message