httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject [multi-env] file/dir renames (was: Re: PATCH [multi-env]: inline functions, apreq_initialize())
Date Tue, 08 Feb 2005 20:34:06 GMT
Joe Schaefer <> writes:

> Max Kellermann <> writes:


>> things to be discussed:
>> - rename apreq.h to apreq_util.h? I find it confusing to include
>>   apreq.h and not to get any of the important libapreq2
>>   features. Maybe rename "apreq_env.h" to "apreq.h" then, because it
>>   provides the core features?
> +1.  Unless someone objects, I'll take care of this rename in a few
> days, once we're caught up on everything else.

Continuing the renaming+consistency theme, I think we should settle
on our header file names being either singular or plural.  FWIW I prefer 
singular, so this is how I plan to rename them:

   apreq.h              ->      apreq_util.h
   apreq_env.h          ->      apreq.h
   apreq_params.h       ->      apreq_param.h
   apreq_parsers.h      ->      apreq_parser.h

After that, a single C<< #include "apreq.h" >> should include every other apreq
header, so their actual names really shouldn't matter to apreq users.

Also I think we should split "src/" into "inc/" + "lib/", move the headers to 
"inc/", and drop the apreq_ prefix from the remaining .c files.  That way
we're left with "lib/" consisting of

      util.c               (was apreq.c)
      module.c             (was apreq_env.c)
      module_cgi.c         (was apreq_env_cgi.c)
      module_custom.c      (was apreq_env_custom.c)
      parser_multipart.c  (was apreq_parsers.c)
      parser_urlencoded.c ("        ")
      parser_headers.c    ("        ")

Next, the "env/" directory needs to be renamed; I suggest "mod/", in
keeping with "inc/" and "lib/".  IMO mod_apreq.c is really too big, and
I think it deserves its own mod/apache2/ subdir so we can break that
file up:

    env/mod_apreq.c ->   mod/apache2/ 

Eventually we should try putting the lib/module_*.c back into mod/ 
somewhere (removing *all* apreq_handle_t constructors from the
library!), but we'd also need to figure out how to support that
idea (portably).  It matches up nicely with our "abstract constructor"
plan for the perl glue, but I don't know how non-perlers will like it.

Joe Schaefer

View raw message