Perl module ideas #1
Below are some of module ideas that I think will be useful someday, but since it's not urgent now, I'm sparing my tuits elsewhere. There will be future posts.
* A module to detect the software of a forum (e.g. vBulletin, phpBB3, etc) and provide some basic API that works for all supported software, e.g.to retrieve threads and posts, open a new topic, reply to a topic, mark topics read, etc.
* Likewise for blog software.
* A module to detect {Yahoo Messenger IDs, Blackberry PIN numbers, street addresses, other contacts} from a text. I have written one for Indonesian phone number, but the others might be useful to extract information from text.
* Something like App::perlmv for MP3 tags.
* App::IniUtils: Command-line utilities to modify INI files, e.g. (ini-add-param, ini-delete-section, ini-sort, ini-comment).
* DOM for Org::Parser.
So many ideas, so little time.
A programmer (mostly Perl 5 nowadays).
My CPAN ID: SHARYANTO. I'm sedusedan on perlmonks. My twitter is stevenharyanto (but I don't tweet much). Follow me on github: sharyanto.
For Org::Parser, could you use XML::XPathEngine or Tree::XPathEngine to add XPath support? I see that elements have parents, children and siblings, so it shouldn't be to difficult to make then look like DOM nodes. Making the document itself behave as if it had a root which has a list of children should be doable, I don't know the format well enough to really figure this out from a quick look at the code.
Let me know if you need help to do this.
Although it's thrilling to do so, I don't think you should put a module in CPAN just because you can. I've worked with my module, Sub::Starter for years before I put it in CPAN. For PDF::Kit, I also worked with PDF::API2 for years. This does increase the quality of the code but, more importantly, it increases the quality of the interface. After working with it for years, you end up with an interface that is comprehensive and easy to use.
If you want to add to CPAN, go through your ~/bin and see what scripts you use all the time. Making these into modules will create a better quality module (and you won't have to spent all of your time correcting bugs. :)
In theory, this is what the Atom Publishing Protocol is for and does essentially. Getting that API implemented properly by software developers and have authors "leave it on" is a different story. The various XML-RPC blogger APIs have the same and more issues.
I don't see why, without a big of thought and the using the Atom Threading Extensions, Atom couldn't be applied to forms.
Just some food for thought.
I would be happy to collaborate on the first idea. I want to do that myself.
@mirod: Thanks for the suggestion. I am more biased towards CSS-selector style, but I will look into XPathEngine.
@shawnhcorey: I believe in the "Release early, release often" mantra :)
@SawyerX: Hi Sawyer! Unfortunately I myself cannot participate at the moment.