APRDesign

[Henrik Vendelbo <hv...@bluprints.com>]

I've been following the thread for a while, and thought I might give my .02 euro....

There is a balance here I believe. Generally I like the APR_ENOTIMPL approach. It
allows you to use the code to build an application expecting that all features in APR 
will eventually be implemented. Using a design principle from OO, it provides a level
of encapsulation, since the user of APR should not design the application based on
knowledge about the internals or current state of functionality of APR.

On the other hand the need to check for succes codes can get out of hand. It reminds
me of the examples in the OS/2 SDK which is filled with int succes = api_call(...) if (succes==
In my experience an API where all functions may return NOT IMPLEMENTED leads to
buggy software since the programmer will not do the succes checks thoroughly. It is 
also difficult to test all the possible combinations of what is implemented and what is not.

My approach would be to have a short list of API functions that may return NOT IMPLEMENTED.

Internally in APR should be a completely different matter. The utility functions used by
APR itself should always be implemented, or not available at all, resulting in a compile or link error.

\Henrik

> > I'd rather not see other platforms hampered because Windows has a run-time
> > only model. I also don't believe that a consistent, available API is a
> > proper goal -- it leads to a least-common-denominator system.
> 
> I have a few thoughts about this.  And it all comes down to who APR's
> users will be.  Right now, they are Apache, but we really don't know who
> they will be in the end.  
> 
> 1) In the future, APR releases will not be tied to Apache, this is a
> given, I think.  If we rely on compile time to determine success or
> failure, it will require a re-compile whenever APR comes out with an old
> feature on a new platform.  If that is okay with you, then fine, I would
> much rather not require a re-compile if I can help it.
> 
> 2) APR does HAVE to have a consistent look across modules on the same
> platform.  This means that functions that are currently no-ops (thread
> funcs on non-threaded platforms), will be changed to be non-existant.
> This severly breaks code in the prefork MPM.  I don't mind breaking code,
> but this is a definite side effect.
> 
> I would rather use APR_ENOTIMPL, because it makes sense to me.  If the
> rest of the group would rather use linker errors, that's fine.  I'm not
> going to get to it anytime soon, because I only have two days before I go
> away for two weeks.  I suggest anybody who feels strongly about this
> change it while I am gone.  :)