[Ayhan] The reason I thought it wouldn't be good is that : 1) The mod_perl standard distribution comes under "Apache::" and it might be useful to distinguish what is "standard" and what is 3rd party, but if mp2-dev doesn't have any problems with that, then it's OK.
What if we the distro decides to adopt some 3rd party modules into the core, like we did with Apache::Reload?
You do have a point there, Stas.
On the other hand, the perl standard distribution can be taken as an example. Normally, the p5p development is mainly concerned with the perl binary, "CORE::", "B::", "IO::", and maybe some+.
On top of that, the standard perl distribution includes many other modules from their own namespaces, like File::Path, File::Spec, and Digest::MD5, just to mention a few. It works perfectly well. Here, the standard distribution acts like a BUNDLE, that's all. (I think it may even be implemented that way too).
Bundle::ModPerl2 or something like that could do the trick.
Come to think of it, I think my main concern here is _not_ the "3rd versus 1st party" issue. It's about separating the API related modules from handlers.
This is something that has always bothered me in the mp1 world. You never knew if "Apache::XYZ" was an API module or a response handler or what. Especially for a new-comer, believe me this is very unnerving.
MP2 has, to a certain extent, resolved this with the "ModPerl::" and "APR::" namespaces. Thanks a bunch for that.
But the "Apache::" namespace is still quite a mess I must say.
It's quite strange that "Apache::FilterRec" and "Apache::VMonitor" live under the same hood. The first is part of the "kitchen" and the other is a response handler that serves up HTML at the end of the day (though it probably sweats quite a lot to do so.)
That being said, there is the backward-compatibility issue which would make it difficult to make such moves. There must be a lot of modules out there which "use" Apache::Request. So it's probably unthinkable to change anything like that.
But when it comes to "Apache::VMonitor" (or any response handler for that matter), that's probably not the case. Those are referenced from within "httpd.conf", that's all. There might be some very rare cases of subclassing, but I bet those would be broken across ports anyway.
I don't think anybody can pass from [apache 1.3 + mp1} to [apache 2 + mp2] without redoing their "httpd.conf". As long as the semantics of the handler configuration parameters stay in place (which is in a way the "api" of a handler), I don't see any problems with changing the module name in httpd.conf.
Then again, I am not alone.... ;) But here's a suggestion anyway
1) Keep backward-compatible API modules where they were :
like :
Apache::Request , ...2) Move all handlers meant to be "executed" by modperl to some place else :
ModPerl::Responder::* (for response handlers only)
ModPerl::Filter::* (for filter handlers only )
ModPerl::Handler::* (for any other kind of handler, including those that hook at multiple phases)
Examples :
ModPerl::Responder::VMonitor
ModPerl::Filter::TemplateWrap
ModPerl::Filter::SnoopIf you don't like ModPerl::, Apache:: could be OK too.
And for very select modules, it should be possible to just subclass them at their "historical" name-spaces for backwards compatibility, provided that they are able to actually support the old API _and_ are able to run under both mp1 && mp2 (preferably by dynamic branching or at worst by
Like :
Apache::VMonitor ISA =>ModPerl::Responder::VMonitorAdvertise the long name, keep the other for backwards-compatibility for some time to come, like twenty years or so ;)
The only problem here would be those old modules that remain in the Apache:: name-space without actually working under mp2. But that should be rare, since most of those are response handlers, and the "compat" module seems to be doing well.
That's examctly the problem, as CPAN (and PAUSE) have no notion of supporting several branches/generations of the module. Unless you ask for a specific version number, it'll always fetch the latest one. That's the issue I'm trying to resolve with CPAN folks. Once mp2 is released we are going to have a lot of complaints of people trying to install mp1 and getting mp2 instead
As you said : implementation details don't matter : You can perfectly have mp1 and mp2 packaged together and let MakeMaker (or the other thing you're using) decide... ;)
Just kidding. But I think it demonstrates how messy these dependency issues can get. And sometimes (but not always), it might just be better changing the name.
For "mod_perl.so", I really don't see any clean way, apart from CPAN handling intricate dependency checks with a min _and_ max version, or some kind of 'flavor' category as you say. Or maybe p5p will accept to put the httpd flavor into the architecture string. Hmmm, isn't that an idea;) Either way, it seems quite messy. Good luck ;)
For API modules, why not use the Apache2 trick, or something similar throughout. I thought that was quite clever of you guys. In a way, it boils down to the architecture-dependent thingy, but is implemented by mod_perl instead of Perl itself.
For handler modules, why not use the scheme above.
Just jotting down ideas here.
Cheers,
Ayhan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
