GetParticipantName and GetRegistryUri

[KonradBreitsprecherBkd]

Add dedicated participant string getters

Summary

This change introduces two dedicated C-API functions:

• SilKit_Participant_GetParticipantName(void* outParameterValue, size_t* inOutParameterValueSize, SilKit_Participant* participant)
• SilKit_Participant_GetRegistryUri(void* outParameterValue, size_t* inOutParameterValueSize, SilKit_Participant* participant)

and their C++ equivalents in IParticipant

• virtual auto GetParticipantName() const -> std::string = 0
• virtual auto GetRegistryUri() const -> std::string = 0

In addition, string copy/size handling was centralized in the C-API layer and tests were updated/extended accordingly.
Further, the new API is used in the sil-kit-system-controller implementation to dynamically retrieve the participant name (set via command line and/or participant configuration). The name has to be added to the required participant names of the workflow configuration. Without the GetParticipantName functionality, passing a new name by config actually failed because there was no way to retrieve the name from the config programatically.

Motivation

The generic SilKit_Participant_GetParameter API in the first draft depended on an enum that looked like it could be expanded to non-string types but actually did not support this. The new design is more simple and exposes the only two relevant participant string parameters directly and clearly. Future parameter queries could be covered by more explicit getters or by retrieving the current participant configuration.

Further Notes

• CapiParticipant.cpp | CopyStringToOutBuffer: string size query and nulltermination handling
• ParameterProvider.hpp | QueryString(SilKit_Participant*, StringQueryFunction): Reusable helper to atomically obtain the string that might change between buffer allocation and query.
• Unit and Integration tests are in place
• Docs are still missing until API is stable

[MariusBgm]

i think we should consider this in a bigger context of providing somthing like service discovery. Not sure if we could add this to a SystemMonitor or some other new Service Entry point, e.g. something stably wrapping ServiceDiscovery.
At the very least, i can think of a SilKit_Participant_GetSimulationName

[KonradBreitsprecherBkd]

i think we should consider this in a bigger context of providing somthing like service discovery. Not sure if we could add this to a SystemMonitor or some other new Service Entry point, e.g. something stably wrapping ServiceDiscovery. At the very least, i can think of a SilKit_Participant_GetSimulationName

The underlying problem is more general: The user currently cannot retreive it's actual (final) participant configuration merged from API calls and a passed Yaml config. Aside from the name and uri, this problem exists for all arguments of CreateController(...) calls that can be overwritten by config. This part is completely local, so I don't see this as part of the service discovery. I agree that this is not a general solution, but simply for uri and name. A general solution would be sth like auto config=participant.getConfiguration() and then work on the config object to extract the values. However for the central property of the participant name, I would expect the API to have a dedicated getter.

The SimulationName is another case, currently it's encoded in the URI, right?

[MariusBgm]

i think we should consider this in a bigger context of providing somthing like service discovery. Not sure if we could add this to a SystemMonitor or some other new Service Entry point, e.g. something stably wrapping ServiceDiscovery. At the very least, i can think of a SilKit_Participant_GetSimulationName

The underlying problem is more general: The user currently cannot retreive it's actual (final) participant configuration merged from API calls and a passed Yaml config. Aside from the name and uri, this problem exists for all arguments of CreateController(...) calls that can be overwritten by config. This part is completely local, so I don't see this as part of the service discovery. I agree that this is not a general solution, but simply for uri and name. A general solution would be sth like auto config=participant.getConfiguration() and then work on the config object to extract the values. However for the central property of the participant name, I would expect the API to have a dedicated getter.

First, I like easy APIs for easy stuff, like this.
However, that was intended by the original design: participants cannot get the current participant name or network name of controllers (think "portable, pre-built participant executables").
Would we add GetNetworkName to controllers, too?

The SimulationName is another case, currently it's encoded in the URI, right?

yes. but my point was, should we create a dedicated API to get the current values from a participant, like participant name, registry uri, simulation name?

Moving away from the old design of not allowing introspection:
a.) either, ad hoc additions of methods to the toplevel participant object, or
b.) create a dedicated, coherent API for introspection (like an enhanced public serviceDiscovery or systemMonitor with participant name, registry uri, simulation name etc).