But we could internally shortcut map_to_storage if transhandler has returned OK, no? Do we really need yet another hook?
I'm kinda against any kind of magic here. apache separates the hooks, probably for a good reason (even if we can't see it at the moment).
Would it still be an added value if we can make PerlTransHandler behave like 1.3 did?
perhaps, but I need to think about it more. the filename errors from map_to_storage have always bothered me, so we need to decide whether we tell API users to set a bogus filename, or write a PerlMapToStorageHandler, or live with the errors. or we have mod_perl do some action-at-a-distance thing.
lemme think about it some. but I'm almost always in favor of a 1 to 1 mapping of Apache hooks and mod_perl hooks, as it keeps with the idea that mod_perl is Perl access to the C API, rather than some magic inbetween API all it's own.
Sounds good. Just remember that we should also try to keep backcompatibility with mp1 and follow the least surprise approach. If we fix that behavior in mp2 it'll work as before for people moving to mp1. If we provide a new hook they will need to change things. and if they need to have the same module working in mp1 and mp2 they won't be able to use the same config, which will be a pain. I'm not sure what's the best approach. It's possible that if we introduce this hook in mp2 we should also do that in mp1.
__________________________________________________________________ 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]
