1000TurquoisePogs
commented
1 year ago There was general agreement on the architecture call that this is a good idea, but another point was raised: The above only guarantees that Zowe will not collide with extensions. Can we help extensions to not collide with other extensions?
Additional proposal: When applying / getting approved for conformance program, a person could apply for a 3-letter code of uniqueness. Then, conformant programs will have guarantees that they do not collide with each other.
Apparently this is also an issue in other Zowe contexts. The Zowe explorer has right click menus in which the ordering and presence of items can be effected by a unique id of a menu item. Since the items can be alphanumeric, then the granted 3-letter code could also be used in that context for uniqueness when desired.
balhar-jakub
Today, ${ZOWE_PREFIX} is something derived from zowe.yaml that zowe itself uses to label zowe core components. It defaults to ZWE, so API gateway might be something like ZWEAG. Extensions currently have no guidance on how to cooperate in this scheme. Extensions want named jobs too, but using ${ZOWE_PREFIX} alone could result in collision with Zowe.
I propose documenting that "X" after ZOWE_PREFIX, such as ZWEX, is reserved for use by extensions. That is, Zowe itself will not be shipping a program that attempts to use ZOWE_PREFIX+X, so that the space has no chance of collision with extensions.