> e.g. Apache::document_root living in Apache > vs Apache::ServerUtil::document_root living where it is now > (Apache::ServerUtil)
actually, it lives in RequestUtil, though it probably should be in ServerUtil. I grep'd through the code and here are the Apache:: functions I find from Apache::URI Apache::unescape_url from ModPerl::Util Apache::current_callback from Apache::Log Apache::LOG_MARK Apache::log_pid from Apache::RequestUtil Apache::request Apache::method_register Apache::get_status_line from Apache::ServerUtil Apache::add_version_component Apache::exists_config_define Apache::get_server_built Apache::get_server_version Apache::server Apache::server_root_relative for the unescape_url(), LOG_MARK(), and log_pid(), I see no reason why they can't live in the classes that define them (that is, changing it to Apache::URI::unescape_url) 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) add_version_component(), exists_config_define(), get_server_built(), get_status_line(), and get_server_version() are all built-in server properties, so put them in Apache::Server as well (defined in ServerUtil). server_root_relative() belongs in ServerUtil, so Apache::Server::server_root_relative() here too. 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. 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. HTH --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
