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
2.0 wishlist: consistent API and docs
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 -jwb
