httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@c2.net>
Subject Re: cvs commit: apache-1.3 STATUS
Date Mon, 30 Mar 1998 14:54:11 GMT
On Sun, 29 Mar 1998, Dean Gaudet wrote:
> Sheesh.  Have I mentioned anything about what comes AFTER the prefix?  NO! 
> I haven't.  If you look at my track record you'll see that I don't create
> obscure function names.  pool_is_ancestor, core_reorder_directories,
> register_other_child.  I may use short local variables such as "p", or
> "i", or "u".  But that is entirely acceptable given that they have only a
> small scope and the short names save thinking time in addition to typing
> time. 

I'm edging in favour of Dean's proposal at the moment. A consistent ap_
prefix It looks much neater and more elgant.

But lets step back a moment, and look at what we are trying to achieve.
We want to give people access to the API at various levels (or that could
be expressed as, give people access to various APIs):

  - basic functionality required on all platforms but where OS support
    varies. Does not require libap. All functions have prefix os_

  - generic functionality useful for Apache and possibly other web or
    general code. This is libap, functions have prefix ap_. 

  - specific functionaliy required only by modules liked to Apache.
    Currently has no prefix hiding, but proposed is apapi_.

  - internal functions, not accessible to modules. Currently has no
    prefix hiding, but proposed is appri_.

In a table, this comes out as

                                 Proposed
   Provider      Directory       Prefix      Used by?
   ------------  --------------  ----------  --------------------------
   libos         os/*            os_         Any portable application
   libap         ap              ap_         Any application, but
                                             targetted to web services
   Apache        main            apapi_      Modules
   Apache        main            appri_      Apache only

At least, this is my assumption. The STATUS file lists palloc() as an
example of something to get an apapi_ prefix, but I assumed that was
because it was not yet in libap. Once it goes in there it should have an
ap_ prefix.

So at some point we will take all the functions current in the Apache
core, and for each one identify it as one suitable for libap (if it does
not require Apache), apapi_ (if it will only work in Apache) and appri (if
it is not part of any provided API). Then the support programs, and
others, can make use of libap (and libos if necessary), while modules can
use ap_, apapi_ and os_ functions (which together make up the "Apache
API"). 

So, are we talking about what to put into the apapi_ and appri_ prefix
boxes above, or are there more fundamental questions, like: do we need a
distinction between ap_ and apapi_ provided functions?

Paul



Mime
View raw message