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: Naming conventions for 2.* (and maybe 1.3+?)
Date Sat, 24 Jan 1998 22:50:04 GMT
Alexei Kosut wrote:
> 
> On Sat, 24 Jan 1998, Rodent of Unusual Size wrote:
> 
> > > is, you can't. While rprintf() is no doubt in the second class, and
> > > snprintf() is no doubt in the first, where does no2slash() fall? It
> > > doesn't care about Apache, it's just a generic utility function that
> > > removes slashes. But it seems very HTTP-ish to me.
> >
> > So what's wrong with it being HTTPish?  Put it this way: differentiate
> 
> Nothing. But which category does it fall into?

I'd say in the httd-neutral utility area - i.e., libap: ap_no2slash().

> > > Well, right now we have os_* prefixed stuff, but I've always thought that
> > > was kind of silly.
> >
> > Why?  It's a level of abstraction, and the name indicates that the
> > routine [potentially] does OS-specific things.  The name's the
> > same, the purpose likewise, but it's a black box with different
> > innards on a per-OS basis.
> 
> Um, no. I'm talking about the prefix of os_. How is os_* different from
> ap_*? I mean, standalone_main() does very different things depending on
> the OS, but I don't see anyone clamboring to add an os_ prefix to it.

os_* is different from ap_* because the code for the former differs from
system to system and embodies understanding of the underlying OS, and
the code for the latter is platform-independent.  There aren't any
ap_* routines under src/os/*, which is where you should look for OS-
specific implementation stuff.

Maybe you haven't heard anyone clamouring for os_standalone_main, but
it sounds like a good idea to me - and there *has* been some recent
discussion about breaking it into OS-specific files.

> > And how to differentiate between categories?
> 
> As I just said: The categories are, IMHO, completely arbitrary, and I
> don't think we need to distinguish.

An example: Digital has for decades had the convention of facDname,
where 'fac' identified the facility (such as SYS for syscalls, RMS
for record-management routines, LIB for general-purpose library
routines, FOR for FORTRAN RTL routines, and so on), 'D' was a delimiter,
and 'name' was a meaningful (usually) identifier.  'D' was either
'$' or '$$' for Digital-supplied code, or '_' or '__' or '___' for
customer-supplied code.  A single character usually means a public
interface, and anything else means a private one.  If you use a
private interface in your code, you're on your own if it changes or
breaks; tough.  Lots of effort goes into keeping the public interfaces
upwardly compatible and semantics-invariant.

While the exact syntax may not map well to Apache, trust me - the
namespace collision issue does.  Digital's system works very well,
and clearly draws the lines between what's a documented API routine
and what's not.  You can tell by looking at the name.  I think
the Apache API would be a lot easier to document <g> if something
similar had been done a long time ago.

This long-winded remark is intended to address your contention that
the categories are arbitrary; my personal opinion is that they
are natural and not arbitrary at all.  But that's just my opinion,
though backed by more than twenty years of coding.  I personally
consider a lot of the UNIXisms sloppy, like the throbbing pustule
of non-reentrant library routines.

While I may lobby bitterly to and past the end, I'll go along with
the consensus - of course.  My opinion is that we *have* to distinguish.

#ken	P-)}

Mime
View raw message