It does it's magic by storing a ParserDetails.ini file in the same directory as SAX.pm is located. They look like this:
[XML::SAX::PurePerl] http://xml.org/sax/features/namespaces = 1 http://xml.org/sax/features/validation = 0
It also gets those features from metadata in the modules themselves (@FEATURES). This is useful for modules that support a common interface, but may require some slight variations.
1) How does this work with PAR?
Internally XML::SAX's doing something like this to get at the file:
[snip many reasons why it doesn't]
Does this make sense? Can anyone spot a flaw in this strategy?
Yeah, it still doesn't fully work with PAR :) Could we not simply define a Module::FileInINC module that would make all that transparent (with saveFileInINC("Foo::Bar.ini")) and work with PAR if PAR is installed? It's not the end of the world writing a file back into a zip. SMOP.
2) More than one place
The big problem I see is where you have local plugins. Imagine that you have global plugins installed in /usr/local/lib/perl/5.8.0 and you want to install some local plugins in /home/mark/perllib. This is a problem as you can't write to the global plugin registry.
IIRC XML::SAX allows you to have another config file be picked up and override the base one if you want to. Not sure if that's enough for what you need.
-- Robin Berjon <[EMAIL PROTECTED]> Research Scientist, Expway http://expway.com/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
