You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2005/02/08 21:34:06 UTC
[multi-env] file/dir renames (was: Re: PATCH [multi-env]: inline
functions, apreq_initialize())
Joe Schaefer <jo...@sunstarsys.com> writes:
> Max Kellermann <ma...@duempel.org> 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
version.c
cookie.c
param.c
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/
handle.c
filter.c
command.c
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.
Comments?
--
Joe Schaefer
Re: Replacing CuTest with Apache::Test
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
[...]
> I've also been working to replace CuTest
> with some Apache::Test-based stuff.
> I want to replace the single "testall" binary
> with independent executables
That's in trunk now (it's not a multi-env issue).
I'm sure Win32 will need updating, but all tests
should pass on *nix.
> Those executables will write TAP to stdout,
> so TEST, SMOKE, and REPORT should (in principle)
> be able to work with them.
At the moment t/ is now Test::Harness based, but
I'm hoping our other resident A-T experts will
help upgrade it to Apache::Test.
--
Joe Schaefer
Replacing CuTest with Apache::Test (was: Re: [multi-env] file/dir
renames)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
>
>> Ok, how about "library/", "include/", and "modules/"? That's
>> similar to "server/", "include/", and "modules/" in httpd.
>> I don't like "src/" much, because that doesn't really
>> describe the .c files within.
>
> +1
>
>> I prefer "modules/apache2". We should also think about
>> renaming mod_apreq to "mod_apreq2", mainly to match with
>> "libapreq2".
>
> +1
Cool. I'll make that happen over the weekend; hopefully
we can figure out how we broke Win32 before that happens.
On a related not, I've also been working to replace CuTest
with some Apache::Test-based stuff. I want to replace
the single "testall" binary with independent executables,
one for each series of tests: "testparam", "testcookie",
"testparsers", etc. Those executables will write TAP to
stdout, so TEST, SMOKE, and REPORT should (in principle)
be able to work with them.
Thoughts?
--
Joe Schaefer
[multi-env] perl glue (was: Re: [multi-env] file/dir renames)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
[...]
> Time to get the perl glue running again.
OK, the perl tests should be running now on *nix. The only major
things that are missing (as far as the tests go) are the Apache::Upload
related APIs. I'll wait a few days before tackling those, so in the
meantime please take a moment to review the changes.
I think the goal for the APR::Request packages should be
to provide a faithful representation of the corresponding apreq_
C APIs, and be flexible enough to implement the old Apache::* APIs
in perl (not XS). To that end, the barebones Apache::Request and
Apache::Cookie perl modules I'm working with are in glue/perl/lib.
I haven't decided what to do with the Apache::Upload APIs, so taking
a pause for commentary now seems like a good idea.
Thoughts?
--
Joe Schaefer
Re: [multi-env] file/dir renames
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
>
>> Ok, how about "library/", "include/", and "modules/"? That's
>> similar to "server/", "include/", and "modules/" in httpd.
>> I don't like "src/" much, because that doesn't really
>> describe the .c files within.
>
> +1
>
>> I prefer "modules/apache2". We should also think about
>> renaming mod_apreq to "mod_apreq2", mainly to match with
>> "libapreq2".
>
> +1
All set (including the mod_apreq2.so rename, FWIW).
Time to get the perl glue running again.
--
Joe Schaefer
Re: [multi-env] file/dir renames
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Ok, how about "library/", "include/", and "modules/"? That's
> similar to "server/", "include/", and "modules/" in httpd.
> I don't like "src/" much, because that doesn't really
> describe the .c files within.
+1
> I prefer "modules/apache2". We should also think about
> renaming mod_apreq to "mod_apreq2", mainly to match with
> "libapreq2".
+1
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [multi-env] file/dir renames
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Max Kellermann <ma...@duempel.org> writes:
> On 2005/02/09 05:14, Stas Bekman <st...@stason.org> wrote:
>> Joe Schaefer wrote:
>
> +1 for Joe's renames.
>
>> >Also I think we should split "src/" into "inc/" + "lib/", move the headers
>> >to
>>
>> "include" is sort for more widely used.
>>
>> "lib" is sort of a perlish thing, so it's a bit confusing.
>
> Agree with Stas.
Ok, how about "library/", "include/", and "modules/"? That's
similar to "server/", "include/", and "modules/" in httpd.
I don't like "src/" much, because that doesn't really
describe the .c files within.
>
>>
>> How about:
>>
>> src/*.c
>> src/include/*.h
>
> only "./src/" and "./include/" would suffice, I believe. The base
> directory is for "libapreq", so there are "src" and "include"
> subdirs. Other sub-projects may live in different subdirs, like
> "mod_apreq".
>
>> or keep the headers along with *.c
>
> We could separate "private" include headers from the "public
> interface" when we create a directory only for public include headers.
Exactly; that's what I had in mind with the header + mfd parser
issue. If that interaction doesn't warrant a public API, we
can just leave a private header file alongside the .c files.
Some future apreq2 might promote that header to a public
API (the version rules allow for adding new symbols), so
keeping libapreq2's public API in separate directory from its
implementation, is IMO a better plan.
>>
>> >"inc/", and drop the apreq_ prefix from the remaining .c files. That way
>> >we're left with "lib/" consisting of
> [..]
>> -0. When loading several files from different projects in the same editor
>> this becomes confusing.
>>
>> +1 to keep apreq_ prefix in all files.
>
> That's a matter of your editor's broken UI, isn't it? ;)
>
> The prefix is redundant and should be removed IMHO, but I wouldn't
> mind keeping it. +0.1 ;)
I don't care for the prefix on the .c files. Besides,
working with different branches simultaneously means
that colliding file names will always be a reality.
AFAICT neither httpd nor apr prefix their .c files, so if
one of our goals is to attract their interest, having a
different set of expectations isn't a good idea.
>
> [...]
>> It's a home of mod_apreq, so why not just call it that way?
>>
>> s|env/|mod_apreq/|
>
> +1
I prefer "modules/apache2". We should also think about
renaming mod_apreq to "mod_apreq2", mainly to match with
"libapreq2".
--
Joe Schaefer
Re: [multi-env] file/dir renames
Posted by Max Kellermann <ma...@duempel.org>.
On 2005/02/09 05:14, Stas Bekman <st...@stason.org> wrote:
> Joe Schaefer wrote:
+1 for Joe's renames.
> >Also I think we should split "src/" into "inc/" + "lib/", move the headers
> >to
>
> "include" is sort for more widely used.
>
> "lib" is sort of a perlish thing, so it's a bit confusing.
Agree with Stas.
>
> How about:
>
> src/*.c
> src/include/*.h
only "./src/" and "./include/" would suffice, I believe. The base
directory is for "libapreq", so there are "src" and "include"
subdirs. Other sub-projects may live in different subdirs, like
"mod_apreq".
> or keep the headers along with *.c
We could separate "private" include headers from the "public
interface" when we create a directory only for public include headers.
>
> >"inc/", and drop the apreq_ prefix from the remaining .c files. That way
> >we're left with "lib/" consisting of
[..]
> -0. When loading several files from different projects in the same editor
> this becomes confusing.
>
> +1 to keep apreq_ prefix in all files.
That's a matter of your editor's broken UI, isn't it? ;)
The prefix is redundant and should be removed IMHO, but I wouldn't
mind keeping it. +0.1 ;)
[...]
> It's a home of mod_apreq, so why not just call it that way?
>
> s|env/|mod_apreq/|
+1
>
> >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/
> > handle.c
> > filter.c
> > command.c
+1
Max
Re: [multi-env] file/dir renames
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>Max Kellermann <ma...@duempel.org> 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
"include" is sort for more widely used.
"lib" is sort of a perlish thing, so it's a bit confusing.
How about:
src/*.c
src/include/*.h
or keep the headers along with *.c
> "inc/", and drop the apreq_ prefix from the remaining .c files. That way
> we're left with "lib/" consisting of
>
> version.c
> cookie.c
> param.c
> 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 (" ")
-0. When loading several files from different projects in the same editor
this becomes confusing.
+1 to keep apreq_ prefix in all files.
In any case you must keep the apreq_ prefix for header files, so having
the *.c files the same way is quite consistent.
> Next, the "env/" directory needs to be renamed; I suggest "mod/", in
> keeping with "inc/" and "lib/".
It's a home of mod_apreq, so why not just call it that way?
s|env/|mod_apreq/|
> 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/
> handle.c
> filter.c
> command.c
unless something has changed recently in the branch you work on (I'm
looking at HEAD) I can't see anything but mod_apreq under the current env/
as for apache2, it's interesting. Do you think apache1.3 might be added at
some point too?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com