Question: customConfig vs hostManifests in v2

[pgn-vole]

Question Area

[x] App Directory
[ ] API
[ ] Context Data
[ ] Intents
[ ] Use Cases
[ ] Other

Question

With the introduction of hostManifests property what is the purpose of the customConfig property from now on?

The API doc of customConfig states:

Array of objects (NameValuePair) An optional set of name value pairs that can be used to deliver custom data from an App Directory to a launcher.

However, this seem to have the same purpose as the hostManifests property because the hostManifests can now too contains launcher specific configuration/metadata entries.

From my point of view I always found the customConfig property a bit odd because it was felt like bag of launcher specific metadata that could easily conflict between each others if 2 launchers for instance rely on a customConfig property of the same name. The hostManifest feels like a much more elegant solution at replacing that kind of use case.

[robmoffat]

I have tried to use this, but since the apps don't have access to this via their metadata, it seems like it's redundant. It would be really handy if this was a way for the app directory to pass config to the app.

I would be very pleased to see this added to ImplementationMetadata

Some use cases:

• I could configure some endpoints in the app to say what data sources It talked to
• I could set up some preferences in the app to say how I want the app to be used

[kriswest]

@robmoffat as discussed at the SWG meeting ImplementationMetadata includes AppMetadata for the app that called fdc3.getInfo() to retrieve it. I suggested we add it to that, but now I'm having second thoughts as I'm not convinced customConfig should potentially be retrievable by other apps (by calling fdc3.getAppMetadata). So perhaps it'd have to be a separate element in ImplementationMetadata as you suggest.

Also as discussed at the meeting, I'm aware that our product and others have their own mechanisms for creating custom config, specified in the host manifest, and for an app to retrieve it (as outlined in the issue). However I'm also keen for the standardized part of the appD record to handle as much as it can without a hostManifest...

@pgn-vole any further thoughts from you given this discussion?

[robmoffat]

@kriswest yes seems sensible that other apps can't access it.

[pgn-vole]

It would be interesting to understand live uses cases of customConfig that cannot be handled via hostsManifests. In our case all customConfig keys (that were application launcher specific), have been moved to launcher specific hostManifests. So only the hostManifest is used to convey metadata from application to launcher.

Ability for a launcher to pass metadata to applications is interesting use case, I would however see such environment specific properties exposed via dedicated fdc3 method rather than having an application directory extending applications metadata at runtime.

[kriswest]

I suspect that there are use cases for app implementations that render different content based on config - e..g. visualizations of industry sectors, pricing tiles etc.. Hence, one use case may be the passing of configuration to an app independent of a hostManifest - for apps that should work on multiple different agents. hostManifests are specific to particular Desktop Agents, where customConfig is not.

Further, the hostManifest is information passed to the Desktop Agent, which only passes part of it on to application(s): the app itself through (await getInfo()).appMetadata and other apps through fdc3.getAppMetadata, in both cases filtered down to what can be encoded by an AppMetadata object. Anything beyond that has to be retrieved via proprietary APIs in the different containers.

Whereas, we could choose to expose customConfig to the application itself through the FDC3 API, perhaps via another field in the ImplementationMetadata Object. A dedicated API call is another option, but seems unnecessary to me. This would make the info available to the application more directly and in a consistent location/standardized way.

(just thinking out loud about potential use cases, rather than specifically advocating for them)

[kriswest]

At the last two SWG meetings (#913 #934) I provided a summary of this issue and asked if anyone wanted to speak for or against the proposed change to make customConfig accessible to apps - no one has taken me up on that offer. Hence, I suggest we proceed with the original suggestion to deprecate customConfig and later remove it from the appD spec entirely.

@pgn-vole @robmoffat

[kriswest]

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).

Hence, it was agreed to close this issue and the associated PR in favour of a new issue to properly serve this use case.

Closing in favour of #1006

[kriswest]

At meeting #1013 it was agreed that customConfig should be deprecated to prepare for

• Custom application config, retrievable via a standardized function #1006
  Which will be based on a new applicationConfig or appConfig element to better represent its purpose, hence, deprecation should go ahead under this issue after all. Reopening.