FDC3 icon indicating copy to clipboard operation
FDC3 copied to clipboard

Add save and restore state API calls - so FDC3 apps can fully participate in save and restore layout

Open lspiro-Tick42 opened this issue 4 years ago • 1 comments

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.

lspiro-Tick42 avatar May 10 '21 15:05 lspiro-Tick42

  • Balance of opinion at #481 was that we should proceed with further discussion, but as an optional part of the specification (MAY)
  • Proposals to be raised or further commentary on issue before adding to a future meeting agenda.

kriswest avatar Oct 29 '21 12:10 kriswest