Jean-Michel Hiver wrote: >>>* If you have two *different* modules which have the same name, then >>>either one, or the other is loaded in memory, never both. This is >>>dead annoying. I think Perl standard modules + CPAN modules should be >>>shared, other modules which are specific to a given script should not. >>> >>And who's to say that a custom module that you write can't end up on >>CPAN??? Or even as a "Standard" module? There may be ways of fiddling >>with @INC to do what you want, but it would be much easier if you, the >>developer, took care to make unique namespaces for your different >>projects... >> > >Consider this. I develop a piece of software in Perl which is quite big. >Therefore it's split into a horde of modules. Now do these modules >changes between versions? Yes (bug fixes, improvements, API changes, >etc). Do the modules name change? Nope! > >As a result I had to amend the software so that it can run multiple >websites. But then if there is a need to change the logic of just one >site I can't just go and change one module because it would change it >for everything else. > >In other words it'd be nice to be able to run different versions of the >same software for different websites on the same server (via virtual >hosts). And that doesn't work. > TMTOWTDI: Make all of your "global (base) functionality" wrapped into some OO Perl module, and then if you need to change specific behavior for certain apps, you can easily subclass it. If the main functionality has to be changed, change the parent object; if it has to be changed for a specific web-app, dump it into the inheritted class. That's one solution, and I'm sure there are others...
> > >Besides this: > >>with @INC to do what you want, but it would be much easier if you, the >>developer, took care to make unique namespaces for your different >>projects... >> > >is highly bullshit. I am not the only developer on the planet. For >instance there is a CPAN module called HTML::Tree. But there is also >another module on the web called HTML_Tree, which installs itself as >HTML::Tree. The developer does not want to rename his module (I >understand that). Even if I install / compile the module locally, >mod_perl is going to screw everything up! Great! > That's the developer's fault. I'm sorry. But that's why you're _supposed_ to check in with [EMAIL PROTECTED] before deciding on your modules namespaces. Just because _another_ developer is using a "taken" namespace doesn't make it "right" enough that special pains have to be made to get around it. And if they _did_, that would be a Perl problem, not a mod_perl related issue! For example, how would you get the CPAN Html::Tree to work in the same script as this other HTML::Tree? You couldn't, because the Perl interpreter wouldn't know what to do with it. Same here! > >>>* Global variables should be reinitialized on each request. Or at least >>>if we want them to be persistent we do not want them to be shared with >>>different scripts on different virtual hosts! >>> >>If you want them reset each time, then reset them to undef manually. >> > > >I think this is wrong. Variables should be reinitialized by default, or >persistent if specified otherwise in some config file. > What if I _want_ a variable that stays consistant across a specific child process' lifetime? Right now, a way _exists_ of resetting variables, but how would you propose to keep them static if your idea was implemented? >>>* Despite numerous heroic efforts, HTTP HEAD requests are still screwed! >>>Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry >>>doesn't work with redirects and 404's (I get like two headers and 3 >>>bodies for 404's. Now that's verbose :-)) >>> >>No real mod_perl problem on that - that's a problem (or maybe >>intentional functionality?) in Apache::Registry and Apache::HEADRegistry... >> > >"intentional functionality". I though that bugs were called features, >but this is even better. I'll have to remember this one :-)))) > ;-) >>don't want to understand the internals of Apache module writing >>(remember that that's the real point of mod_perl: to write Apache >>modules in Perl instead of C), whereas mod_perl means pre-writing >> > >True, however the real point of Apache::Registry is to "run unaltered >CGI scripts under mod_perl" and it just doesn't work properly does it? > No. That's Apache::PerlRun. Apache::Registry usually needs some tweaking to run properly. There's plenty of information about that in the guide under the HUGE portion devoted to CGI_to_mod_perl_porting (or even in the special manpage under the same name). >>Of course, that's the power of mod_perl over mod_php. And I know that >>personally, it's why I use it. As to the non-ISP friendliness >>disadvantage, that's a critical issue, but I think it's being >>re-analyzed for mod_perl 2.0 >> > >Do you know where to find mod_perl 2 related info on the web? I'd be >interested in knowing what's it gonna be. > Not really sure. I asked about that and got the current state of the mod_perl 2 docs from CVS, but I, too, would like to see something on a "Beginner" level somewhere on the Net. Maybe if/when I get around to reading it and understanding it, I can try to help out there... Issac
