in reply to RFC: App::SFDC

Hi ali0sha,

It's too late now but I would have tried to not create yet another new namespace on CPAN ...

There was already:

The last named of which was created by you a few days ago!

I know that CPAN is littered with poorly chosen namespaces, and when you want to contribute a new package, you often have to steer clear of them, and often want to choose a better name anyway. It's hopeless, and getting worse every day, as ironic hipsters post their Dist:Zilla plugin bundles, or even just their CPAN install bundles, as ... CPAN modules (!)

But I dunno, if you were going to put your utility routines under WWW::, couldn't you have worked with the existing WWW::Salesforce, which is apparently well-maintained and -reviewed ... And if the app was going to be under one namespace, I would have tried to put all components under the same space. As I understand it now, your dist is um, distributed between App::SFDC and WWW::SFDC ...

Please don't take this too personally. It's a pet peeve of mine, and you did ask :)

The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^2: RFC: App::SFDC
by ali0sha (Sexton) on Jul 14, 2015 at 13:51 UTC

    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:

    • Salesforce
    • WWW::Salesforce (WebService::Salesforce should actually be part of this dist)
    (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.

[reply]

      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