in reply to Re: RFC: App::SFDC
in thread RFC: App::SFDC

Hiya,

I completely understand your frustration about namespacing - in fact, I was thinking carefully about this when I created the modules.

To first address App::SFDC - this lives in the App:: namespace because it's a command line application. Those other things are not - I feel pretty safe on this one.

Then to address WWW::SFDC - I feel strongly that this is a separate package from App::SFDC because it provides a usage-agnostic wrapper around the APIs. So basically, I think the crux of your feedback is; why did I choose to write my own wrapper, WWW::SFDC, instead of expanding on one of the existing ones, specifically:

(I'm excluding Net::Salesforce and DBD::Salesforce as they are doing fundamentally different things, viz. an OAUTH wrapper and a DBD library respectively)

The main difference between WWW::SFDC and the two existing modules is scope; Salesforce offers several SOAP APIs, including the Partner, Metadata, Tooling and Apex APIs. I need a library which will allow me to easily transition between all of these different APIs to perform intricate operations. However, WWW::Salesforce and Salesforce only wrap around the Partner APIs, and to extend them to work through all of the existing APIs would have meant effectively a ground-up rewrite and be completely backwards-incompatible.

Despite this, I contacted Fred Moyer (the WWW::Salesforce) maintainer in December to see whether we could work together on the project, but he only replied to me once, and I was moving really fast on getting this up and running.

What would you have done differently in this situation? At this extremely early stage, I could, if I got in contact with one of those maintainers and manage to work it out, transition to a different namespace, but I think these are fairly good grounds for going it alone.

Replies are listed 'Best First'.
Re^3: RFC: App::SFDC
by 1nickt (Canon) on Jul 14, 2015 at 14:27 UTC

    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.

    The way forward always starts with a minimal test.
[reply]
[d/l]

      Thanks for the suggestion, I'll place a 'Why use this?' or 'See Also' or something which explains this in the next version.

[reply]

In Section Seekers of Perl Wisdom