* has_pod_index: The POD contains at least one X<> keyword that helps
POD indexers. Whether only one is usefull is open for debate, because
at least the license (X<gpl>), your CPAN ID under authors (x<tels>),
and some generic keyword what your module (X<foo>) is about can
probably added even for the most minimal module.
Can you give an example of how this has any practical impact on
anything?
Here is the main page for the project.
http://pod-indexing.annocpan.org/wiki/index.cgi
They talk only about the Perl core doc at this point, probably because
adding keywords there is already enough work. AFAIK the core docs are now
covered, so individual modules would be next.
Yep, a google-like search engine could save the effort of manually tagging
with keywords, but I think this idea is more practical and will improve
perldoc greatly.
I hate to say it, but this indexing thing has seemed to be ass-backwards
to me from the beginning.
Instead of having one person combine a Pod Parser and Plucene indexer or
some other simple process, they expect the 3500 authors to ADD extra
content to all their POD?
It seems like an absolutely terrible case of CYJ... making the life of
the search engine writer easier by making everyone else change.
Having the coverage kwalitee bit was bad enough, but supporting a
project like this seems far far worse, as I'm not how you this is
supposed to be any better than a natural text search of CPAN would be.
In fact, it occurs to me I've just uploaded CPAN::Mini::Extract, and if
you tied that to Plucene you could probably _have_ an indexer for such a
Google'esk search up and running in a day or so.
The signature one I don't mind as much, signatures are at least
supported in most places and make some kind of sense at some level :)
Adam K
