Sounds like you did everything you could have. As I said, it was mostly a general rant.
The main flaw in CPAN in my opinion is that there is simply no option to move or even delete a namespace once it's created.
I can grok not deleting ever; and it is possible to get control of a zombie and at least edit it to state that it is dead. But not being able to move dists means that as everything expands (CPAN itself, the world that CPAN dists connect to, and the functionality of the dists), the structure can never be reorganized or optimized. For example, by combining working dists, that have claimed a general namespace which they don't fully deliver on, with new dists, like yours, that either complete the functionality or introduce an abstraction level that the old dist should be under. In the case of Salesforce, that can never happen, so your dist, which is more complete and newer, is forced to live alongside others in the hierarchy, and a user just searching for a Perl interface to Salesforce.com is left to sort it all out for himself.
The only thing I think I would suggest is to make sure to put a section in your POD explaining the history of the solutions offered for the problem you are tackling. I rely on such a "History" or "Rationale" or "Why this module" section from the author quite often when trying to choose a CPAN package. The response you posted above would be most of what you needed to say. And it's not any kind of mea culpa, but just a road map for the user who is searching for your code, but just isn't sure about that yet.
In reply to Re^3: RFC: App::SFDC
by 1nickt
in thread RFC: App::SFDC
by ali0sha
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |