perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <a...@phase-n.com>
Subject [Fwd: Some questions about mod_perl 2.0]
Date Thu, 30 Dec 2004 03:13:11 GMT
Hi guys

I'm just reading through the docs of the new mod_perl and I had a couple
of questions. (and maybe issues).

Perl/CPAN Tool Chain
--------------------

I'm just finishing up PPI.pm at the moment on a Perl Foundation grant,
and I know a lot of perl tool chain modules (autodocumentation,
dependency checking, API detection, autodocumentation, PAR, etc etc) are 
likely to end up using it in some form or another...

I'm wondering how you plan to make the modifications to the various
modules that might be effected by this new concept of "two different
modules (APIs) with the same name"

Are you going to be taking over CPAN.pm and CPANPLUS.pm, or contributing
patches to make it handle it?

How will you tell what to install when someone does

perl -MCPAN -e 'install My::Module'

How will you know that a) It is an Apache2-related module and b) which
version to install?

Do you have a patch yet for modifying the PAUSE indexer to handle this?

I'm also little worried about dependency-scanning tools too.

At the moment when I give a bit of code to a dependency scanner, it
finds the string 'use Foo::Bar;' in my source and knows I have a 
Foo::Bar module dependency, whether or not it has that module installed 
itself.

If you are going to have multiple modules with the same name, how do you
plan on resolving this?

Also, dependency logic and config data throughout all of CPAN and the 
entire perl/CPAN tool chain is currently listed in "Foo::Bar 1.23" form, 
where it takes any version of Foo::Bar higher than 1.23.

It would seem that the entire tool chain is also going to need to be 
moved to use something like only.pm, where the dependency is done as a 
complex expression... is this right?

If I want to uniquely identify one of an arbitrary number of APIs within 
a single namespace, for example to make a database key in my tool that 
parsers all of CPAN to find bugs in the PPI lexer, what should I use?

Threads
-------

My second question is related to the thread-safe'ness issue.

Some of the docs say that everything is going to need to be thread-safe
now. Does this mean I can only include CPAN modules if they are thread-safe?

If so, do you have a solution for detecting if any arbitrary code or 
module is thread-safe or not?

There are 14 million lines of perl in CPAN, are we going to have to
rewrite all of them to make them thread-safe before we can use any of
them with mod_perl 2.0? We have enough problems maintaining some of them
already...

I would imagine that many modules can't be made thread-safe without 
fundamentally changing their APIs as well... do you see a risk of API 
cascade here, where a significant percentage of the 8,000 CPAN packages 
have to be rewritten to be able to use them in mod_perl?

Making the "Multiple APIs per Package" Decision
------------------------------------------------------

Finally, a general question. I'm wondering why you chose to keep the
same namespace for a totally different API, instead of moving to Apache2
like some other modules like the SQLite modules have done (to SQLite2
and SQLite3) when their APIs needed to change to match a new underlying
API. I'm not aware of any other cases that did something like this other
than GD, and that has frankly been a total disaster. It generates
something like 90% of my support requests even to this day, despite
being only one small support module of a secondary project of mine (CVS
Monitor).

The use of GD has been abandoned in many cases (I would have done so if 
I had the time to do it) simply because, for several years, it's been 
near impossible for any user to install it successfully.

Is the decision process that led you to choose to keep the same
namespace documented somewhere so I can understand a bit easier, or was
it an arbitrary decision?

My immediate thoughts are that if (for the most part) all modules need 
to be rewritten or changed in order to work with Apache 2, that would 
seem to fit quite well with Apache2:: as you would add a re-written 
version for each of the hundred or so Apache-related modules as 
Apache2::XXXX instead of Apache::XXXX.

This would leave Apache 1 users with a support legacy version, and newer 
projects can move to using Apache2:: at a pace that suits them.

It would also mean you could have alternative authors much more 
easily... For many CPAN modules the original authors may not even be 
around any more (see the File::Remove Changes file for an example).

How are you planning on allowing the CPAN indexer to support multiple 
APIs by different authors occupying the same namespace at the same time?

Thanks in advance for your assistance

Adam Kennedy
http://search.cpan.org/~adamk/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message