Re: 2.0 wishlist: consistent API and docs
On Wed, 26 Apr 2000, raptor wrote: > What about a Apache2::XXX namespace for the new modules ...??! > just asking. not quite, but there's a MP_INST_APACHE2=1 Makefile.PL attribute which will install everything relative to an Apache2/ subdirectory. this way 1.xx mod_perl and 2.xx can co-exist in the same site_perl tree then to enable 2.xx, just add 'PerlModule Apache2' in your httpd.conf, which adds the Apache2/ subdirs to your @INC path.
Re: 2.0 wishlist: consistent API and docs
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.
Re: 2.0 wishlist: consistent API and docs
On Tue, 25 Apr 2000, Matt Sergeant wrote: > On Tue, 25 Apr 2000, Jeffrey W. Baker wrote: > > > I wish for a consistent API and documentation in the upcoming mod_perl 2.0 > > implementation. For example, right now, we have several different ways to > > tweak outgoing response headers. Some headers have their own method > > ($r->content_type), while others are aggregated ($r->header_out). Some of > > the ones that have their own accessor have slightly tweaked method names > > ($r->set_content_length). Worse, the documentation conflicts with the > > implementation. perldoc Apache says "You should not define any > > 'Content-XXX' headers by calling [header_out], because these headers use > > their own specific methods." However, there is no method content_length, > > you either have to set it using header_out, or use Apache::File and get > > set_content_length. > > > > 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. Regardless, I propose a more consistent API for mod_perl > > 2.0. When setting an outbound header, I would prefer to use all method > > calls. I would also be fine with using a generic method like > > $r->header_out. However, I think that accessor method interface is > > preferrable because it lets us plug in funky logic that may be needed when > > a header is set. The header_out interface can have that too, but only if > > it switches on the hash key, in which case it is just identical to but > > slower than the accessor method interface. > > > > That's my two cents. Since I'm bitching about it, I volunteer to help be > > the interface and documentation police for 2.0 > > I'm with you, as long as you can do: > > PerlModule Apache::BackwardsCompatible I agree.
Re: 2.0 wishlist: consistent API and docs
On Tue, 25 Apr 2000, Jeffrey W. Baker wrote: > I wish for a consistent API and documentation in the upcoming mod_perl 2.0 > implementation. For example, right now, we have several different ways to > tweak outgoing response headers. Some headers have their own method > ($r->content_type), while others are aggregated ($r->header_out). Some of > the ones that have their own accessor have slightly tweaked method names > ($r->set_content_length). Worse, the documentation conflicts with the > implementation. perldoc Apache says "You should not define any > 'Content-XXX' headers by calling [header_out], because these headers use > their own specific methods." However, there is no method content_length, > you either have to set it using header_out, or use Apache::File and get > set_content_length. > > 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. Regardless, I propose a more consistent API for mod_perl > 2.0. When setting an outbound header, I would prefer to use all method > calls. I would also be fine with using a generic method like > $r->header_out. However, I think that accessor method interface is > preferrable because it lets us plug in funky logic that may be needed when > a header is set. The header_out interface can have that too, but only if > it switches on the hash key, in which case it is just identical to but > slower than the accessor method interface. > > That's my two cents. Since I'm bitching about it, I volunteer to help be > the interface and documentation police for 2.0 I'm with you, as long as you can do: PerlModule Apache::BackwardsCompatible -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
