On Tue, 25 Apr 2000, Jeffrey W. Baker wrote:
> The origin of these inconsistencies has, I think, been the years-long
> development of both mod_perl and Apache 1.x. Some headers may have their
> own accessors because they need to tweak something in the Apache core when
> they get set.
i'll take blame for the poor docs, certainly something that will be fixed
with 2.0. as for the api, i think mod_perl is already consistent with
Apache's, with a few tweaks here and there to make things more Perlish.
if you think Apache's api is inconsistent, then let's fix it there, i
don't want to move too far away it in mod_perl. while i agree it's kinda
awkward that certain headers have their own get/set functions, rather than
dropping/getting them raw into the headers_{in,out} tables, it's only done
where needed. e.g. $r->set_content_length() not only adds the header to
r->headers_out, it updates another field in the request_rec (r->clength)
i don't want to add get/set method for all possible headers_{in,out}, that
would bloat things. of course, you could implement an Apache::Headers
modules that does this, but i don't want to add too many methods that the
Apache api doesn't implement in the mod_perl "core".
Apache.xs is a kitchen sink, expect to see it broken out into smaller
modules (ala Apache::File, Apache::Log), that add methods into the
Apache:: namespace.
before any of the 2.0 code is written that glues into the request_rec and
friends, i plan to writeup a layout of the classes/methods and where
everything lives. we can sort out any issues then before the api is
implemented.
