You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some feedback from the Belfast meeting was that it would be useful to have configuration providers which can inject information about resources into the system topology relevant to a particular environment.
Some initial thoughts, I wonder if such an interface could be used to add entirely new resources to the topology or to simply add additional information to resources. I think the latter should be relatively straight forward, providing the resources available in the system match the expectations of the configuration provider. The former may be more complicated, adding new resources could be fairly trivial if we provide a way to create resources and populate its information, the difficulty
would come in when defining connections or possible contentions with existing resources in the system topology.
It was pointed out that this is also a nice solution to the problem we have of how to define non-standard domain-specific identification of the abstract C++ resources. If configuration providers can see the topology when injecting information then they could be used to provide concrete labels for specific resources, even by just checking their names. Then these configuration providers could be provided open-source supplementary to the standard.
The text was updated successfully, but these errors were encountered:
Some feedback from the Belfast meeting was that it would be useful to have configuration providers which can inject information about resources into the system topology relevant to a particular environment.
Some initial thoughts, I wonder if such an interface could be used to add entirely new resources to the topology or to simply add additional information to resources. I think the latter should be relatively straight forward, providing the resources available in the system match the expectations of the configuration provider. The former may be more complicated, adding new resources could be fairly trivial if we provide a way to create resources and populate its information, the difficulty
would come in when defining connections or possible contentions with existing resources in the system topology.
It was pointed out that this is also a nice solution to the problem we have of how to define non-standard domain-specific identification of the abstract C++ resources. If configuration providers can see the topology when injecting information then they could be used to provide concrete labels for specific resources, even by just checking their names. Then these configuration providers could be provided open-source supplementary to the standard.
The text was updated successfully, but these errors were encountered: