Zowe Client SDKs: global SDK specification discussion

[KUGDev]

The proposed structure to have:

• core
  • datasets
  • files
  • jobs
  • tso
  • console
  • ...
• impl
  • zosmf
    • datasets
    • files
    • jobs
    • tso
    • console
  • ...
• connection
  • zosmf
  • cmci
  • apiml
  • rse
  • ftp
  • ...

There are also some other things to discuss, such as:

• how the interfaces/abstract classes for request and response objects would look like
• how the impl would look like (separate modules for each / just folders for each of the SDKs with Zowe's default implementation)
• what APIs are we counting on exactly (other than the listed ones)
• the conformance options (to include as the best practice or do not nclude)
• the place where the docs will be (+ what format)
• probably some other things

[KUGDev]

The next call to be (possibly) discussed: Oct 17

[zFernand0]

I believe the next Architecture call (Oct 03) will be used as the Pre Pi Planning (Kick-off) meeting.
Maybe the next one?
I'm open to a completely new meeting, if we want to discuss this sooner. 😋

[KUGDev]

@zFernand0 yes, I've changed the date, it will be the 17th of October

[gejohnston]

I am posting some comments into this issue to provide discussion points for the on-going conversation.

The proposed design is coherent. I see no reason to object to the use of such a structure in any new language SDK.

I feel that an action to overhaul existing language SDKs will be problematic. Revising an existing SDK will likely involve many months of code modification, manual testing, and fixing automated tests. It is hard to justify such an investment, since after that commitment of time, the SDK (and its consuming apps) will have no new functionality.

A much greater concern is the likely negative response that we will receive from current consumers of any existing SDK that is overhauled. We have proposed far smaller modifications to an existing SDK which received feedback from consumers that the modification of consumer apps to accommodate the SDK changes would be more work on the part of the consumers than they were comfortable undertaking. As a result, some previously proposed SDK modifications were abandoned. I think that this proposed change to existing SDKs would require an order of magnitude greater modification on the part of consumers. We may receive very negative feedback from consumers about a requirement for them to make such changes.

I understand that identifying an approach as a best practice is not a binding commitment. However, if most existing SDKs are not altered to conform to that approach, then it might seem misleading to call it a best practice. Can we genuinely refer to something as a best practice, if the majority of our contributions do not adhere to that practice?

[KUGDev]

@gejohnston thank you for commenting. I agree that the "best practice" for the issue would be a missleading term, as the existing SDKs will should make their codebase to follow these rules. But it is still could be as a proposed way to build any new SDK upon. Given this, we should define the way of treating the issue then

[zFernand0]

Hey all,
Not sure where we left this topic last time it was discussed.
Curious if we can close this issue in favor of:

• Zowe SDKs - contribution guidelines docs-site#2487

Or maybe the other way around (close the docs-site in favor of this one)?

[KUGDev]

Hi @zFernand0
Our team didn't have time to work on this issue still
Probably it is better to move it somewhere in a more specific place first, and then, when we are ready, discuss it
I propose converting it into Zowe Kotlin Client SDK's issue