Construction of CDS Name inconsistent with other named elements

[zanzaben]

Is your feature request related to a problem? Please describe.
For the api functions dealing with the CDS the variable name has multiple meanings. For RegisterCDS() it wants the CDSName.
GetCDSBlockIDByName() and GetCDSBlockName() both use the full cds name (of the format "AppName.CDSName"). The header file for these don't explain the difference very well either.

Also there is no easy way to get a full CdsName from the CdsName because the function that does that CFE_ES_FormCDSName() is not public.

Describe the solution you'd like
There should be more clarity in the differences as well as a way to get the full CdsName, like having the register function pass back the full name or making the formCDSName function public.

Describe alternatives you've considered
They could all use the same thing.

Requester Info
Alex Campbell GSFC

[astrogeco]

CCB:2021-04-21

• What is GetCDSBlockIDByName()? There isn't a way to easily construct these.
• We have a "GetCDSBlockName" but it requires knowledge of the "ID".
• What is the use case for this? Might have been driven to do namespace collision avoidance.
• @jphickey to check that GetBlockName and GetIDByName
• Do we want to be consistent and "namespace" everything?

[skliper]

For other elements the passed in name is the full name that can be used in the get by name APIs. For CDS the name passed in for registration is different from the CDSName (it get's prefixed with AppName). If the concept is to share CDS blocks (like sharing tables) the name should be consistent, vs internally modified... or we could go the other way and prefix everything, but that makes it harder to share since you need to know the original context.

[jphickey]

I did confirm on this that the CFE_ES_GetCDSBlockName() function is correctly the inverse of CFE_ES_GetCDSBlockIDByName(). Both deal with the real/fully-qualified name.

We have the same facililties for all resource types - users always have a function to get the real/fully-qualified name of any resource (app, task, pipe, etc), which can then be put into a file or message, and an equal/inverse function to get the ID if they have the fully-qualified name from a file or message.

IMO the pattern employed by CDS to qualify the name with the owning app is a good idea as it helps avoid collisions. We should consider implementing something similar for Child Tasks, Memory Pools, Counters, and perhaps SB pipes as well (although the latter usually matches the app name which has to be unique anyway). Can't do it for apps/libs for obvious reasons.

[skliper]

Worth a trade, there's advantages when sharing (such as table) to have an easy way to reference an object that was created elsewhere. Would also impact commands that utilize names. I definitely recognize there are use cases where it could be an advantage but it is an additional complexity that should take requirements and resources into account. Could be handled with a few new APIs or maybe falling back to the unqualified name, but that adds an additional set of error cases that would need to be handled. I'm not sure it's really worth the additional complexity... could just error on creation if a duplicate name is used and let the user manage it (less logic in FSW vs adding complexity).

EDIT - As long as a good naming pattern is employed duplicates will be avoided by design...

[jphickey]

I concur about the good naming pattern - if there is a documented naming pattern and it is implemented in the app/config, there should be no need to munge names in the code. But one can just as easily (if not more so?) implement the name pattern in the code, thereby enforcing consistency in the pattern, not relying on apps to "be good".

I think the crux of this issue is that its weird that only CDS has internal name-munging. While I think its beneficial, it is an outlier. One can easily just configure all the CDS block names with a prefix and take this out.

But as far as sharing goes, it should not be an issue either way. Most runtime sharing/API-based exchanges are done through the ID value, which is always a direct/unambiguous reference to a specific resource. The only time this comes into play is when it is put into a file or command as a name, rather than an ID value.

We should either put the app name prefix onto all resource names that are logically "owned by" or associated with an app, or we should put it on none of them. Having it only on CDS blocks is odd.