httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Apache 2.0 alpha. (again) :)
Date Tue, 21 Mar 2000 04:29:05 GMT
On Mon, 20 Mar 2000 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.
> [ blow by blow reply... missing the point ]

Ryan -- you're missing the point. By your definition, *anything* could go
into APR. If a function is needed to make something portable (e.g. a way
to access files and sockets), then it goes into APR. If a function isn't
part of that set, then it is inherently part of a library of functions, so
THAT goes into APR, too.

You have no dividing line.

Manoj and I are trying to point out a line to use:

1) functions which implement inherently non-portable stuff in a portable
   fashion. e.g. sockets, files, pipes, efficient memory allocation

2) functions which use no OS facilities and are (therefore) inherently

When APR was started, I believed it to be #1 only. The other utility
functions are just that -- utilities. They don't serve to make programs
more portable. All you're providing is packaging, not portability.

Rather than see APR become a big bag of unfocused bits, I'd rather see it
become stuff to make things portable. The "general" stuff should go into
its own package and compete on merits against things like mhash, mm, glib
(not to be confused with glibc), and similar libraries/toolsets.


Greg Stein,

View raw message