-----BEGIN PGP SIGNED MESSAGE----- Moin Ivan,
On Sunday 06 November 2005 17:39, Ivan Tubert-Brohman wrote: > Tels wrote: > >>>* 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. > > We are not done with the core docs yet; the list of documents that are > done is listed at > http://pod-indexing.annocpan.org/wiki/index.cgi?IndexStats . The next > stage in my plan would be to index the modules that come with the core > distribution. Indexing CPAN modules is up to each individual author and > I haven't really thought much about it yet. Understood. > Much as I love the POD indexing project, I'm reluctant to see this > added as a kwalitee point. First, because there are already enough > complaints that CPANTS is trying to "force" authors to do things in one > specific way needlessly; and second, because it would be too early > anyway, as pod indexing still needs to be tested in practice. Fair enough. > Getting off topic: I still have to figure out how a perldoc -k would > handle indexing of CPAN modules. The problem is that having too many > things indexed could be counterproductive. For example, doing "perldoc > -k pop" will give you the pop function ( > http://pod-indexing.annocpan.org/perldoc-k.cgi?keyword=pop ), but what > would happen if you index all of CPAN and there are dozens of modules > that implement a "pop" method? I'm thinking that the best solution > would be to have the option of doing a "core search" vs a "global > search"... I thought about this, too, and I think that the search result lists will ultimatelvily be big - after all, there will be a lot of things having the same keyword. So, reducing the set of returned "hits" must be done. Adding too much keywords is not a good idea, but then, we have no experience on what is "too much" and "too little". OTOH, I do think that adding a keyword with the name for each function is not a good idea, namely because you would get hundreds of hits for "new". Hm, maybe like so for methods: X<method> X<new> and for non OO: X<function> X<convert> Then you could search for "method and new" (I think having the ability to search for more than one keyword is absolut nec so that the results do not overhelm the user :). Should this discussion be continued on another mailinglist? Best wishes, Tels - -- Signed on Sun Nov 6 17:50:48 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "My glasses, my glasses. I cannot see without my glasses." - "My glasses, my glasses. I cannot be seen without my glasses." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ2415XcLPEOTuEwVAQH7cAf6A/jzDt4qxOou+Qy4PL+ThlyUp7SlrWX5 9eGGwxIEzjC6KR5LThJAmJJpJQXxuLU1kaNOvydNzbYO9a9ISg8/4T2k9K0UtvNX LX6wFktIFoky2U6T8xtmK6ywNYBx1CM7X3SgJlgm+CfVgX8fwovaWlS9UdcEJ80R /lQiF8YI9kbvgsfCUTRxf+5B40cMfU9uDmRQhHoxnfZe8bQaEsMSUKJQ7nZIMn1W tVChXkJssKTWgoHcOBUK64e7ARJp2Zig0VFIodBlgtYffZj34lM0KgAYC4LTA1O9 +h0Qi6XdFFGAJhABAIBjhCIJ2eEJZOAP8nP/2CAGmdICZYucQVh0vw== =mZiN -----END PGP SIGNATURE-----
