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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
