> >* 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.
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!
> >* 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.
> >* 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?
> 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.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 221 4968
================================================================
VISIT HTTP://WWW.MKDOC.COM
