httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <>
Subject Re: Apache 2.0 alpha. (again) :)
Date Tue, 21 Mar 2000 12:44:01 GMT wrote:
> > > APR's job
> > > is to provide other projects an easy way to make their code portable, and
> > > to provide a library of functions that they won't need to re-implement.
> >
> > And here's the rub. I think there needs to be more of a focus here
> > than that.  With this as the only crieteria for inclusion in APR, it
> > then can swallow the functionality of GUI widget libraries, XML
> > parsers, cryptography code, database access interfaces, PostScript
> > parsing, WebDAV filesystem abstraction, and distributed DoS attacks.
> > :)
> Let's take these one at a time.

I think the focus is getting a little fuzzy though.

Is APR meant to be a super-package that provides a whole bundle of
functionality that Apache needs to be present on an OS or is it meant to
be a portability shim for making Apache easier to port/maintain?

There are already open source packages that do some of the things and I
don't see any reason to fold them into, or re-implement them in APR. It
duplicating open source effort and is bordering on NIH syndrome.

> GUI widgets:  Yep, these would be potential candidates if enough people
> wanted it, and it could easily be isolated from the rest of the code.
> XML parsers:  No, this isn't a potential candidate.  XML parsers are a
> very specific _application_, APR shouldn't be implementing applications,
> just making it easier for others to do so.
> cryptography code:  Yes.  And, it would be a good place to do so.  If I am
> writing a portable program, I want to make sure that the cryptography is
> as portable as possible, by putting it in APR, I know it is portable.

FreeBSD has invested a lot of effort in native cryptography code based
on the OpenSSL package. I'm in favour of Apache creating crytography
shims in APR so that there is a portable interface to platform dependent
implementations but I think it is the wrong way to go to put an actual
implementation in to APR.

If you carry this process to the extreme APR becomes a complete
operating environment rather than an application library!


View raw message