httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: Apache 2.0 alpha. (again) :)
Date Tue, 21 Mar 2000 21:18:06 GMT
Ok - now I see all the venom over this issue I re-raised.  My appologies to
all who didn't care for the lengthy debate.

Seems to boil down to this (please correct my assumptions):

APR is a collection of code with no explicit purpose other than faciliating
cross platform development.  The functions are generally kernel functions or
helpers on par with the core C library.  It is a top level library, in that
it should rely on no other code.

AP is the collection of other code that has no explicit purpose other than
sharing what we already do, with other apps.  It is NOT necessarily top
level, and requires some APR to do it's good work.  But it relies on no
other code.

Other libraries will be included to specific purposes.  An example today is
regex.  If they are bound to APR or AP, that's fine.  If they stand on their
own, that's fine too.  Either way, we let others leverage them.

ApacheCore is our server.  Any code that is specific to our application
resides here.  Anything that depends on the ApacheCore resides here.  If it
is generic, it doesn't belong here.

These can be built into libraries (or win32 dll's) in whatever organization
we care for.  The binaries are platform dependent.

If this is the case, I started in the wrong place (ap) rather than at APR.
But no matter, let me take this one issue.

We will presume that ap.h is the core definitions of the ap library.  Not
the core, not the apr, nothing else.  It will include apr_lib.h to keep
itself happy.

These declarations in ap_hooks make little sense;

extern AP_VAR_EXPORT ap_context_t *g_pHookPool;
extern AP_VAR_EXPORT int g_bDebugHooks;
extern AP_VAR_EXPORT const char *g_szCurrentHookName;

On g_pHookPool, do we agree another application would only use one HookPool,
ever?  The threading issues, especially with g_szCurrentHookName, are a
nightmare.  If so, then we need to actually export it from ap_hooks.c.  If
not, then ap_hook_sort_register, ap_sort_hooks (as well as sort_hook), and
the IMPLEMENT_HOOK_BASE define all inherit an additional argument.

g_bDebugHooks could stay here, if we actually export it from ap_hooks.c.  If
not, ap_sort_hooks (as well as sort_hook), and the IMPLEMENT_HOOK_BASE
define all inherit an additional argument.

As an alternative, we can export these within the invocation of
IMPLEMENT_HOOK_BASE, tokenizing a unique name based on the name arg.

To be generic, IMPLEMENT_HOOK_BASE() needs an additional arg, the name
string.  And then we slide g_szCurrentHookName from the ap_hooks header over
to apache, which exports it.  Using the alternative, we can stringize the
name arg.

Whoever pointed out that ap_hooks, amoung the others, did not belong in APR
was certainly correct.  I'm not being hostile here, just pointing out that
if we are going to pontificate on how 'portable' and 'modular' the 2.0 will
become, we need to actually make project units both portable and modular.

Sorry in advance if this ruffles feathers.  I will be happy to submit
whatever makes sense to the group for the ap updates.  I've finished the
Win32 portability aspect (creating AP_EXPORT* macros applicable to these
modules alone).

View raw message