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

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

[ moved to dev@apr.apache.org ]

On Fri, Dec 22, 2000 at 10:06:54AM -0800, rbb@covalent.net wrote:
> > 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.

It does become difficult, but we can do this in major revisions of the
library. That will create a "porting" effort to upgrade to another major
rev, but it is fine from a compile/link standpoint -- shared libs have
revision numbers and an app build against APR 1.0 won't accidentally try and
load APR 2.0 instead.

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

Yup. I heard some of the same nightmares from the CRTL folks at Microsoft.
Backwards *and* forwards compatibility is a huge effort. It can be quite
painful to do :-)

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

True, but these APR_HAVE_*_H macros are kind of an edge case. As Jeff points
out, they aren't always needed by APR. However, I think they're suspicious
to begin with, and I think that I've got a good solution to them.

> >   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
> >   HAVE_GETADDRINFO (and thus APR_HAVE_IPV6)...
> 
> 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
> cross-platform.

See my other note for increasing the portability of #include.

> > Happy holidays...
> 
> Right back at yah :-)

Ditto, all!

Cheers,
-g

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