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: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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 :)
well, I don't think it's hell. a bit of a pain, yes...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.
;)
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
