cleaning up Apache:: namespace

[Geoffrey Young <ge...@modperlcookbook.org>]

I just couldn't keep up with the multiple threads under the old subject :)

>> my reading of method_register() is that it's global to all requests - it
>> doesn't make sense to define a new http method during a request.  so,
>> move
>> that to Apache::Server::method_register() (defined in ServerUtil)
> 
> 
> It actually does, see the example at:
> http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler
> 
> though I see no reason why not to have Apache::Server::method_register()
> 
> +1

using it that way means that you attempt to register the EMAIL method for
the entire server for every call to that uri, even though its scope is for
the lifetime of the server - it doesn't un-register at the end of a request.

so, I'd suggest changing that example a bit. mod_dav calls
ap_method_register during post_config, so maybe that's a better place for
it.  beware of which pool you use as well.


>> current_callback() is a tough one.  maybe we could do it similar to
>> server_root_relative: support only object methods but both
>> $s->current_callback and $r->current_callback, since it's phase related.
> 
> 
> why? if it can work transparently to where it is called from, why
> complicating it with requiring an object? I think it's just fine with
> how it is. Just move it to Apache::Server::current_callback. Actually I
> thought that it really belongs to ModPerl::Util::current_callback since
> it gives us mp callbacks, not the apache ones.

hmm, ok, maybe you're right.  but I think I prefer
Apache::Server::current_callback() - if we used ModPerl::Util it would make
it the only API in the ModPerl namespace (I think) which is kinda strange.

> 
>> that leaves Apache::request and Apache::server.  I may have changed my
>> mind
>> about these, thinking it best to keep them where they are.  But
>> Apache::RequestRec->new() and Apache::Server->new() also have a certain
>> appeal, so long as everyone understand the singleton-esque nature of the
>> constructors.
> 
> 
> I'm not sure what new() has to do with it. But I'm certainly fine with
> Apache::RequestRec->request and Apache::Server->server I'd even add the
> current_ into the API. Do you think they need to be class methods and
> not just functions?

I need to think a bit on these.  for one, there's already an
Apache::RequestRec->new and I need to see what it does.

at any rate, that's enough for one day :)

> 
> This change will require special "ifdef" on the modperl version in
> certain CPAN modules, like CGI.pm :( So it's not only about those brave
> bleeding edge users, but CPAN authors hell.

well, I don't think it's hell.  a bit of a pain, yes...

--Geoff


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: cleaning up Apache:: namespace

[Stas Bekman <st...@stason.org>]

Geoffrey Young wrote:
> I just couldn't keep up with the multiple threads under the old subject :)

but also what would have helped is not to reply to the same message, but start 
a new one and copy the reply to it. You've changed the subject but mail 
clients still file them under the original thread, because of the:

References: <40...@stason.org> <40...@modperlcookbook.org> 
<40...@stason.org> <p05111b02bc2d5348ab0b@[192.168.56.3]> 
<40...@stason.org> <p05111b06bc2d5b097c63@[192.168.56.3]> 
<40...@stason.org> <p05111b07bc2d5dce2295@[192.168.56.3]> 
<40...@stason.org> <40...@modperlcookbook.org> 
<40...@stason.org>

>>>my reading of method_register() is that it's global to all requests - it
>>>doesn't make sense to define a new http method during a request.  so,
>>>move
>>>that to Apache::Server::method_register() (defined in ServerUtil)
>>
>>
>>It actually does, see the example at:
>>http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler
>>
>>though I see no reason why not to have Apache::Server::method_register()
>>
>>+1
> 
> 
> using it that way means that you attempt to register the EMAIL method for
> the entire server for every call to that uri, even though its scope is for
> the lifetime of the server - it doesn't un-register at the end of a request.
> 
> so, I'd suggest changing that example a bit. mod_dav calls
> ap_method_register during post_config, so maybe that's a better place for
> it.  beware of which pool you use as well.

Good point, Geoff. I'll fix the example.

>>>current_callback() is a tough one.  maybe we could do it similar to
>>>server_root_relative: support only object methods but both
>>>$s->current_callback and $r->current_callback, since it's phase related.
>>
>>
>>why? if it can work transparently to where it is called from, why
>>complicating it with requiring an object? I think it's just fine with
>>how it is. Just move it to Apache::Server::current_callback. Actually I
>>thought that it really belongs to ModPerl::Util::current_callback since
>>it gives us mp callbacks, not the apache ones.
> 
> 
> hmm, ok, maybe you're right.  but I think I prefer
> Apache::Server::current_callback() - if we used ModPerl::Util it would make
> it the only API in the ModPerl namespace (I think) which is kinda strange.

Why? We will surely add more in the future. But for example calling 
Apache::Server::current_callback() at the server startup sounds wrong. Since 
there is no server at that point.

>>>that leaves Apache::request and Apache::server.  I may have changed my
>>>mind
>>>about these, thinking it best to keep them where they are.  But
>>>Apache::RequestRec->new() and Apache::Server->new() also have a certain
>>>appeal, so long as everyone understand the singleton-esque nature of the
>>>constructors.
>>
>>
>>I'm not sure what new() has to do with it. But I'm certainly fine with
>>Apache::RequestRec->request and Apache::Server->server I'd even add the
>>current_ into the API. Do you think they need to be class methods and
>>not just functions?
> 
> 
> I need to think a bit on these.  for one, there's already an
> Apache::RequestRec->new and I need to see what it does.

I think that one is handy for the yet-to-be-written FakeRequest based on APR. 
Or may be not, that FakeRequest shouldn't depend on modperl.so. I'm not sure then.

> at any rate, that's enough for one day :)
> 
> 
>>This change will require special "ifdef" on the modperl version in
>>certain CPAN modules, like CGI.pm :( So it's not only about those brave
>>bleeding edge users, but CPAN authors hell.
>  
> well, I don't think it's hell.  a bit of a pain, yes...

;)

__________________________________________________________________
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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org