Comments (8)
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.
from fdc3.
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
from fdc3.
@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?
from fdc3.
@kriswest yes seems sensible that other apps can't access it.
from fdc3.
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.
from fdc3.
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)
from fdc3.
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
from fdc3.
At meeting #1013 it was agreed that customConfig
should be deprecated to prepare for
- #1006
Which will be based on a newapplicationConfig
orappConfig
element to better represent its purpose, hence, deprecation should go ahead under this issue after all. Reopening.
from fdc3.
Related Issues (20)
- Adding Event Listeners on Private Channel HOT 1
- Inconsistent Use of Promises HOT 6
- Bug or Inconsistency? HOT 1
- Question: AddContextListenerResponsePayload does not contain channelId HOT 2
- FDC3 monorepo HOT 2
- Use Cases and Workflows Discussion Group - 1st August 2024 HOT 5
- Make Listener.unsubscribe() async for consistency HOT 7
- Simplify Web Connection Protocol HOT 7
- IFramePositioning HOT 12
- RaiseIntentResultResponse HOT 5
- Question: resolvers / channel selectors UI HOT 5
- Spelling Error: FindIntentsByContextsResponse HOT 1
- broadcastEvent on no channel HOT 7
- Adding Channel State For JoinUserChannel / AddContextListener HOT 1
- Question: IntentEvent has no targetApp property HOT 3
- Question: How does DesktopAgentProxy remove event listener? HOT 3
- window.origin Requirement HOT 2
- Standard WG Meeting - August 22nd, 2024 HOT 8
- Add .NET docs for Events to API reference HOT 1
- GetAgentParams Not Optional HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fdc3.