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
{{ message }}
This repository has been archived by the owner on May 22, 2020. It is now read-only.
The goal is for services to be able to retrieve desktop owner level settings. Much of the details surrounding what these look like can be found here.
The proposed API would be added to the v2 System namespace as:
fin.System.getServiceConfiguration({name: 'whatever'}).then(conf=>{conf.name//=> whateverconf.appDirectoryHost//=> https://app-directory.openfin.coconf.manifestUrl//=> https://example.org/services/whatever/app.jsonconf.config//=> {service specific json blob}}).catch(err=>{/* xyz service is not configured in desktop owner settings file... */})
Do we care about which app directory it was fetched from here (appDirectoryHost)?
This assumes that service configurations are not "private" per se, meaning that any app can get any service configuration. To restrict this info to just the service itself we would need some work provide apps with the concept of being a service and an identity as such.
I think that there is a larger conversation around service discovery and the apps themselves actually knowing that they are being launched as services that needs more discussion.
The text was updated successfully, but these errors were encountered:
This covers what we need to support our services use-case. We still need to know the name of the service, which does add some possible complexity on our side - but that's manageable if there's reasons for that decision.
Just out of curiosity:
Does the API return the full/"raw" JSON data as it is defined in the desktop owners file, or is it picking-out specific properties? Are any of the properties in the returned object optional?
Are there any restrictions on who can call this API, or which service configurations you are allowed to read? For instance, could a service read the configuration of another service? Or could an application read the configuration of a service?
Would it be possible to make the name optional? At which point the API would return the configuration of whichever app(/service) is calling the API? Or alternatively, something like getServiceConfiguration(null)/getServiceConfiguration({name: 'me'}), etc?
Is there a reason the API takes an object? Are there any properties allowed other than name? Could we pass an identity object there, for instance?
Do we care about which app directory it was fetched from here (appDirectoryHost)?
We don't have any kind of use for this on our side at the moment, but could possibly have one in the future. Certainly no objections to this being added, or any other additional data.
It would return the blob of json that corresponds to the service named service, e.g.
{ ...
"services": {"layouts": {// if you ask for 'layouts' you get whatever is here}, ...}}
For now anyone would be able to ask for any service config. To restrict this we would need to add the concept of actually being that service and not "just an app launched by the RVM". Doable if we feel its important enough.
Sure, would require the same work for the point above
Continuity with similar getters (window and app getCurrent both take id objs) and extensibility
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Api to retrieve desktop owner settings for services
RUN-5112
The goal is for services to be able to retrieve desktop owner level settings. Much of the details surrounding what these look like can be found here.
The proposed API would be added to the v2 System namespace as:
Do we care about which app directory it was fetched from here (
appDirectoryHost
)?This assumes that service configurations are not "private" per se, meaning that any app can get any service configuration. To restrict this info to just the service itself we would need some work provide apps with the concept of being a service and an identity as such.
I think that there is a larger conversation around service discovery and the apps themselves actually knowing that they are being launched as services that needs more discussion.
The text was updated successfully, but these errors were encountered: