httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject 2.0 header file rearrangement
Date Thu, 16 Mar 2000 22:20:34 GMT
On Thu, Mar 16, 2000 at 12:27:03PM -0600, William A. Rowe, Jr. wrote:
> From: Manoj Kasichainula [mailto:manojk@io.com]
> > This sounds ugly to me. I agree with Bill here.
> 
> Which of us :~?

Ack. You are now officially designated as OtherBill. :)

> - but I agree this does not address what CORE_PRIVATE was
> ment to accomplish.  My thought is CORE_PRIVATE is a code permissions flag
> (this module is spying where it shouldn't so to speak), more than some
> module-inclusion flag for linkage.

*shrug* Whoever put that in way back when can expound on this.

> The http_core.h privates have dependencies on its publics.  Therefore these
> cannot be drawn into a single header without requiring httpd.h _and_
> http_core.h be included prior to http_core_private.
[...]

This feels like it's getting too complicated to me, because of
sticking to current practice. I'd advocate a complete rearrangement of
the header files.

Here's my idea (names to change):

Public Headers
--------------
- httpd.h: public interfaces that are not exported by the core module,
  a.k.a. the HTTP protocol module
- http_core.h: public interfaces that are exported by the HTTP
  protocol module

Private to Apache plus src/modules/standard
----------------------------------------------

- ap_config_auto.h: All facts determined about the system at
  build-time (generated right now by autoconf)
- ap_config.h: All the decisions that are made based on the data in
  ap_config_auto.h. This is called ap_ac_config.h right now, but since
  I get no firm sense of how the group wants files moved in CVS, I
  haven't actually renamed it yet.

Private to Apache, not including src/modules/standard
-----------------------------------------------------

- {httpd,http_core}_private.h: Same as above, but for private
  interfaces. Probably not even put into src/include.  These could
  also be split up to correspond to the individual .c files. They
  would #include the appropriate public API header files as necessary.

Public interfaces would not be segregated at all by the private .c
file they are located in unless the functional separation is
*extremely* clear. And I think it should always be possible for the
module author to just include one or two header files from Apache and
not worry about it.

Since I'm proposing something requiring more work, I can volunteer to
do it, though I can't promise doing it in less than a week.


Mime
View raw message