Ok. Working through the docs(converting to mp2-API) the following question came to my mind:
Are there any rules, which (response-)method is in which module? - no_cache is found in Apache::RequestUtil - update_mtime/set_last_modified are found in Apache::Response - content_type is found in Apache::RequestRec - headers_out/error_headers_out are found in Apache::RequestRec
Doesn't they all belong to Apache::Response, they all deal with the Response, don't they?
Now is the perfect time to move things around if we find that things aren't intuitive and could get better laid out. That's what I've been doing for the last few months, while working on the docs and tests.
content_type, headers_out, and err_headers_out are all a part of the C request_rec structure. for the most part, these accessor methods merely perform a get/set on the request_rec slot with little or no intervention, so we put them in the Apache::RequestRec class. notes, headers_in, and a few others are also in this class (since they are part of the request_rec structure also). think of RequestRec as using the official Apache API to access the request_rec slots (if you think that way :)
May be we need to take a different view and find their homes according to their end user functionality, not their internal structure. I agree with Tom that most users, who don't care about C api compatility, will find it much more intuitive to see all methods that are needed to generate response headers in Apache::Response. Though it'll break the concept of RequestRec containing request_rec accessors.
while no_cache is also a slot in the request_rec, as a convenience mod_perl adds some useful manipulations when calling $r->no_cache - it will also set/unset the Pragma and Cache-control headers to make no_cache() more intuitive. thus it lives in RequestUtil, as a method firmly based in $r (the request_rec) but with added mod_perl sugar. other similar methods are $r->dir_config and $r->as_string.
May be we could move no_cache into Apache::Response if it makes things more intuitive.
the rest of the Apache API goes into a bunch of other classes, specific to the API's task. so there is Apache::Response for dealing with response-type things (like caching headers), Apache::Access for dealing with access/authen/authz things (like get_basic_auth_pw), and so on.
if you kind of get your head around this it does make sense after a while :) actually, stas and I agreed just last night that Apache::Server and Apache::Connection should be broken down in the same way, so the next release of mod_perl will have Apache::ServerRec and Apache::ServerUtil instead of a global Apache::Server class with everything thrown in.
Right, ServerRec is already in.
-- __________________________________________________________________ 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
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
