Custom application config, retrievable via a standardized function

[kriswest]

Enhancement Request

Use Case:

Issue #900 sought to clarify whether customConfig was still relevant in the appD spec since the hostManifests were introduced. At SWG meeting #1005 a number of participants spoke up for a use case for custom configuration that could be retrieved by an application using a standardized function, where the config might affect the behaviour of the app (and do so in vendor-agnostic fashion). E.g. a market sector visualization or blotter might be filtered by region (APAC, EMEA, etc.).

This is a different use case (intended for apps, vendor agnostic format) to that of the hostManifests entry (intended for the DA itself, proprietary format, may be retrievable via proprietary APIs).

The customConfig field is currently only retrievable via proprietary APIs as there is no standardized function for retrieving it. Were it to be retrievable in a standardized fashion, it might be used to vary the definition of applications via config alone, in a way that should work in all compliant desktop agents.

Further, it was suggested that the name of the element could also be refined to better identify its purpose, e.g. applicationConfig.

Hence, this issue seeks to:

• deprecate customConfig in the appD record,
• create applicationConfig as an unstandardized object with string field names in the appD record,
• create a means of retrieving any applicationConfig defined for an app in their appD record,
  • For example it might be added to the ImplementationMetadata object returned by fdc3.getInfo() as appConfig or a dedicated function might be added to the API, e.g. const config = await fdc3.getAppConfig()