-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add save and restore state API calls - so FDC3 apps can fully participate in save and restore layout #386
Open
Labels
enhancement
New feature or request
Comments
lspiro-Tick42
changed the title
Add save and restore state calls - so apps can participate in save and restore layout calls
Add save and restore state API calls - so FDC3 apps can fully participate in save and restore layout
May 10, 2021
11 tasks
|
9 tasks
21 tasks
21 tasks
32 tasks
26 tasks
29 tasks
26 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Enhancement Request
Use Case:
Most FDC3 Desktop Agents (aka Containers) support the ability to load a layout (a set of applications placed at certain positions on the screen) and the matching save layout request. There may be used defined layouts and system defined ones.
This proposal ignores the requirement to track window positions and start/stop applicatons. Desktop Agent can provide this functionality. This proposal defines additions to the API to allow FDC3 Applications to provide their internal state to be included in the save layout and restored during the load layout.
The scope of the internal state will vary from application to application but will include things like view type, filters, sort orders etc.
it may also include selected items like a trade, an instrument or a contact, but this requires further discussion.
For example:
A layout may contain windows that are showing a client, their portfolio and some information on a selected stock. Say the three windows are all set to the same channel, and the desktop agent allows the user to save the layout.
Each application should be presented with an API for making its state available (during the save request) and then receiving that state during the load layout state. From an FDC3 PoV the state would be a blob (assume JSon) and it's format would be application speciic.
If this use case is adopted there are at least two API' styles that can be used for saving the state. Either an Async call which the desktop agent can invoke to request the state on demand for an FDC3 application, or a requirement for the applications to publish any changes to their state to the Desktop Agent.
I have a preference for requesting state on demand, but maybe we should support both styles. Although the 'push state' does require FDC3 to agree a standardised instance identifier.
The text was updated successfully, but these errors were encountered: