httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: cvs commit: apache-1.3/src/modules/standard mod_expires.c mod_include.c mod_log_config.c mod_rewrite.c mod_usertrack.c
Date Mon, 30 Mar 1998 01:53:05 GMT
apapi_vformatter contains no dependencies on the core. 

I don't see the point in having 5 million different prefixes.  I don't see
the point in having 5 different prefixes.  I would rather have one prefix
and use it everywhere.  At the moment we've got the following:

AP_	stuff that doesn't have any other prefix
ap_	some stuff that fits your description of generic library tools
	with no dependency on core (i.e. ap_snprintf), and some stuff
	that does depend on core (i.e. ap_escape_quotes)
apapi_  two random new core functions
aplog_  another random core function
os_     some other random core functions

... and at least one more that's proposed but unused, appri_ or whatever
you want to call it.

This is ridiculous.  Apache is 72k lines of code.  If we can't keep our
own symbols from colliding with each other then we've got serious problems.
We need only one prefix.

Dean


On Sun, 29 Mar 1998, Rodent of Unusual Size wrote:

> dgaudet@hyperreal.org wrote:
> > 
> > dgaudet     98/03/28 03:58:37
> > 
> >   Log:
> >   Finally dealt with the vformatter() thing that's been sitting in STATUS
> >   since october.
> > 
> >   - apapi_vformatter() is generic printf-style routine with arbitrary
> >     output
> 
> Blimey!  I'm offline for three days while I install a new computer
> desk, and the world tilts!
> 
> I haven't looked at this yet, but is it really "apapi_" - that is,
> it contains dependencies on the httpd core, like pools or something?
> Remember, ap_snprintf() was *not* dependent upon the core for
> anything, and thus was broken out into libap so it could be used
> by non-httpd things.
> 
> If the new vformatter() doobie is like this, the name should be "ap_"
> rather than "apapi_".  If it *does* contain dependencies, can it
> be further reduced to those pieces that do and those that don't,
> so the parts that don't can go into libap for general use (i.e., inclusion
> in the nascent "Apache Reusable Software Library" effort)?
> 
> Or am I being a total ass for speaking up without checking first?
> 
> #ken	P-)}
> 
> Ken Coar                    <http://Web.Golux.Com/coar/>
> Apache Group member         <http://www.apache.org/>
> "Apache Server for Dummies" <http://WWW.Dummies.Com/
> 


Mime
View raw message