* On Sat, Apr 05 2008, Eric Wilhelm wrote: > It appears that our current strategy is this: > > * rely on a proprietary web application for search (search.cpan.org)
I like kobesearch better. I hear the code for that is available, which is the main reason I like it better :) I haven't actually looked at the code yet though (or talked to Mr Kobes). > * create multiple, unconnected web apps hosting diverse information > * mention and apologize for the above web apps in a wiki (web app) > * count on fewer than 10 people to keep the web apps working > > So, I would love to see a better strategy -- probably involving more web > APIs and desktop clients, but definitely with more openness. I've wanted easily-available CPAN-related APIs also, so I wrote this (with the help of brian d foy++): http://git.jrock.us/?p=MetaCPAN.git;a=summary This indexes the BACKPAN and CPAN and lets you ask questions like "what version of Foo::Bar was current on January 8th 2004?" or "give me all dists containing Quux::Baz, in release order". I needed this feature for git-cpan, which is also on the back burner for now. (git-cpan == every cpan module + history available in a read/write git repository. Now that everyone's using git anyway, I think this would be even more useful than when I thought of it... but it's a tuits issue right now :) Basically, tell me what sort of data you want available through the REST interface, and I will take care of finding the data and keeping it up to date. You can also have the sqlite database if you want (it's about 200M right now). I haven't had time to write the sysadminy stuff yet (get cpan via rsync, reindex new modules, etc.) ... or the web interface for that matter... but all the data gathering and analysis stuff is there. Patches welcome! Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
