httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: httpd-2.0/support ab.c ab.dsp htdigest.c htdigest.dsp htpasswd.c htpasswd.dsp logresolve.c logresolve.dsp rotatelogs.c rotatelogs.dsp
Date Fri, 22 Dec 2000 18:06:54 GMT

> minor issues which will come up:
>   APR (or projects which APR developers work on) stops caring about
>   some test and the APR_HAVE_xxx is removed from apr.h => this is a
>   bug because it can break some app we've never heard of; in other
>   words, we'll have a slow growth in configure tests which we may stop
>   caring about 

This is something the APR developers are going to need to start to be
aware of.  Basically, we are creating a library now, instead of an
application.  This comes with a different set of rules for developers.  It
should be very difficult, if not almost impossible, for us to remove a
macro or function from APR.

I worked for Digital for a brief period on the team that did the C
Run-Time library, and it was almost impossible to remove a feature, we
need to follow that same model.  If you look at how APR has grown, we have
very rarely added something that we didn't REALLY need.  The idea is that
if we don't need it, we don't want to support forever, so we don't add

>   apps don't necessarily gain when there is a hodge-podge of tests
>   performed by APR and tests performed by the app; if the app has to
>   perform tests at all, it is better off doing them itself

The problem is when there is a test that both APR and the app have to
make.  The thing is that we don't want apps to make any test that APR is
already doing, because it just gets confusing.  Also one of the biggest
complaints about Apache before it started using APR for the header
checking, was that Apache was duplicating all of the tests that APR was
making.  If APR is a good portable runtime, then apps shouldn't need to
test for anything that APR is already testing for.

>   apps may not want to respect our judgement on subtle issues; take
>   mmap() for example; we originally had a test for mmap() which failed
>   on OS/390...  APR didn't use the part which failed, Single Unix (or
>   some doc I read) cautioned against the use of that feature, etc.;
>   now our idea of HAVE_MMAP (and thus APR_HAVE_MMAP) is based on
>   something that is closely related to our code...  similar with

In cases like this, the app has the option to do it's own checking, and
ignore APR.  This is why APR has namespace protected all of its
checks.  But, if the app does it's own check, then it is likely to remove
some degree of portability.  Remember that APR tends to do a lowest common
demoninator type of checking, so that we only support what we can support

> Happy holidays...

Right back at yah :-)


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message