httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: IOL's in APR.
Date Fri, 12 Nov 1999 08:24:59 GMT
Option 2 is basically an interface change from option 1; there's no
real added code bloat, just a couple of added function pointers stored
in the type, so it's okay.


Option 3:
It would be less work, just as clean, and slightly more functional to
just throw the current IOL code in APR, and just add new constructor
functions that create the file and push it into the IOL for us. This
is Option 2 to the outside world, with option 1 implemented

There is one minor advantage of doing this, which is that if a
function can only handle raw files and not sockets filtered by
buffering filtered through SSI, then the function can "enforce" this
by specify (ap_file_t *) in it's declaration.

On Wed, Nov 10, 1999 at 03:24:28PM -0500, Ryan Bloom wrote:
> The promised variation on the APR types.  ALL APR types have a context
> associated with them.  Currently, it is not possible to retreive that
> context.  It would be possible to put the context into the same type as
> the IOL functions, and the context would then be easily accessible.

I've don't like this very much. It puts a context into the IOL API,
meaning that every IOL must have a context defined, even if there's no
particularly good reason to give it one. And, it will get used as a
out-of-bad channel for information, which I think this is a great way
to obfuscate how a program works for new participants.

Manoj Kasichainula - manojk at io dot com -

View raw message