httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: cvs commit: apache-1.3/src/test/rename apapi.h apapi.h.mk rename.cf
Date Tue, 07 Apr 1998 02:12:57 GMT
Ralf S. Engelschall wrote:
> 
> ap_ is part of both variants in STATUS: Once for the real API functions in the
> first variant and as the general prefix in the second variant. In the first
> variant ap_ is there because apapi_ is really too long and I personally really
> think the libap stuff should be threated as API stuff. So, ap_ for all public
> API stuff is best: It's Apache specific and its short.

You forgot the obligatory "IMHO" in the last sentence.  I'll presume it's
there, but implied.

Please, let's drop this guff about "apapi_ is too long."  That's
a personal opinion, no more.  I've been having to deal with X API names
(extremely minimally, thank goodness!) and other library API names that
look like lib$convert_date_string and str$find_first_not_in_set - and I've
dealt with names like this for years.  It's not necessarily good, but
neither is it necessarily evil.  If name length adds to clarity, I'd
generally lean toward it begin good as a prejudice.  (Those are
pathological examples that I think would be candidates for shortening -
but it's not my API.)

So let's discard that argument, please.  The points here, it seems to me,
are

 1. What are the namespaces that need to be defined?
 2. What should the prefixes be?

[1]
All of the namespaces need some sort of protection (probably via
prefixing the names) to avoid collisions with known and unknown
external symbols.  The namespaces we've been using loosely have
been

a) OS-specific drop-in replacements that do black-box things in
   OS-specific ways.  This is just a more elegant (though
   potentially harder to maintain) way of doing it than #ifdef'ing
   a single source file.
b) The Apache Web server API (request_rec, the p* routines, et alia).
c) The Apache Web server non-API internal stuff (e.g., construct_server,
   server_argv0).
d) Reusable routines that are used in the Apache Web server but
   aren't dependent upon it.

It seems to me (still not caught up yet) that the argument on the table
is whether these should all be in the same namespace (e.g., ap_mumble)
or separate ones.  Worst case is we don't do anything except point-fixes
to symbols known to be colliding; best case (philosophically) is giving
*all* the symbols appropriate prefixes as part of 1.3 and not waiting
for 2.0.  (Pragmatically this may not be the best time; I'm with
Marc on that.  But the majority rules..)

[2]
The two options under discussion at this point seem to be:

A) Give everything the same prefix (i.e., no class distinctions)
B) Prefix according to class

In order, the prefixes we've been using for the above classes are

a) os_mumble
b) none (sometimes ap*, rarely apapi_*, mostly nothing though)
c) none (sometimes ap*, mostly nothing)
d) ap_mumble

There, have I stated this accurately?

My personal preferences are

a) no opinion
b) apapi_mumble
c) ap*_mumble (not ap_, not apapi_)
d) ap_mumble

#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>

Mime
View raw message