Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 29514 invoked by uid 6000); 30 Mar 1998 02:32:01 -0000 Received: (qmail 29489 invoked by uid 24); 30 Mar 1998 02:31:59 -0000 Message-Id: <3.0.3.32.19980329174127.00a04240@hyperreal.org> X-Sender: brian@hyperreal.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 29 Mar 1998 17:41:27 -0800 To: new-httpd@apache.org From: Brian Behlendorf Subject: prefixes In-Reply-To: References: <351EDBE3.417C94D1@Golux.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org At 05:53 PM 3/29/98 -0800, Dean Gaudet wrote: >apapi_vformatter contains no dependencies on the core. Moving it to ap_vformatter was the right thing to do, then. >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) That should be cleaned up. What other funcs besides ap_escape_quotes? Looks like that's the only func in src/ap that takes a pool pointer as a parameter, and could probably be modified to handle static buffers... >apapi_ two random new core functions >aplog_ another random core function Looks like consensus is to use apapi_ for API functions. >os_ some other random core functions Wasn't this for routines that turn OS-nonspecific semantics into OS-specific calls? My vote would be to make this ap_. >... and at least one more that's proposed but unused, appri_ or whatever >you want to call it. I think the AP_ system makes this unnecessary anymore, true? >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. In so far as we want to have a 1) library of reusable code and 2) real API, having distinct prefixes is helpful. Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- "Optimism is a strategy for making brian@apache.org a better future." - Noam Chomsky brian@hyperreal.org