httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: cvs commit: apache-2.0/src/lib/apr/include apr.hw apr_config.hw
Date Wed, 05 Apr 2000 15:52:28 GMT
> ap_oslevel is an internal APR function [...]  I am -1 on
> making this a public function until we have seen a program 
> that actually requires this knowledge.

No argument.  Specifically, I agree with the premise that 
apr should be written so that APR advertises it's own 
function support or lack thereof.  Therefore, we never 
should rely on platform or version testing.  

i.e. defined(APR_SUPPORTS_DSO), for example, should be a
true or false indicator to follow a code path.  If that 
won't do (and perhaps, somewhere down the line, it won't 
for run time os version resolution) then it's an 
ap_dso_supported() function instead.  Either way, we
should not live in 

However, MPM's (which are platform specific) reinvent
this functionality today.  I realize more and more of
MPM will leverage the APR, but it will yet and still
need to make decisions based on the platform.  (Why
else would we invent multiple MPM's?)  We've already
kicked around the thought of 2 MPM's, NT and 9x.  So,
consider the MPM case before you set the final 
decision in stone.  (As I said, I'm happy to keep it
internal today, alpha's are more mudflows than stone :~)

Bill


Mime
View raw message