Support changes to the set of User Channels in the Desktop Agent API

[robmoffat]

Minor Issue

Area of Issue

• App Directory
• API
• Context Data
• Intents
• Desktop Agent Bridging
• Use Cases
• Other : DACP Protocol.

Issue Description:

The new event listener system supports an event userChannelChanged which allows the desktop agent to tell an app that its user channel has changed.

In the latest fdc3-agent-proxy code, this is used to update the injected ChannelSelector in the following piece of code:

// DefaultChannelSupport.ts

this.channelSelector.updateChannel(theChannel?.id ?? null, this.userChannels);

However, this uses an internally-cached selection of user channels (this.userChannels), which is presumed to not change after the app has loaded.

However, it seems sensible that the selection of user channels might change, as the user may configure more or rename them.

We should therefore support a second event (e.g. userChannelsUpdated) that the Desktop Agent can send to the proxy to let it know that there is a modified set of user channels.

Additional Context:

• User channel change issue #1541
• When the User Channel Changes, DA Proxy ContextListeners fail to recognise the change #1540

[kriswest]

The issue description is slightly conflating the API event userChannelChanged event with the (related) DACP message that delivers it (from the DA to the app), ChannelChangedEvent.

The first thing we need to consider is whether changing the set of User channels (created by the Desktop Agent) is something that should happen in FDC3 - the (Desktop Agent) API specification doesn't explicitly ban the channels changing, but it also doesn't provide any support for it; apps can retrieve a list of the user channels, but there is no event that they can listen for that will announce changes to that set. That lack then feeds into the Desktop Agent Communication Protocol not including a message for the DA to tell the DA Proxy (and any injected channel selectors) that the set has changed.

If changes to the set of user channels (rather than just which user channel is selected) is use case that community recognises as something that FDC3 should support, then we should add both an event to the API and messages to support both firing that event and passing updates to DA Proxy, which it can pass onto any injected channel selectors so they know about the new channel set.

However, it seems sensible that the selection of user channels might change, as the user may configure more or rename them.

I guess this then prompts the question of whether changing the set of user channels is a feature that Desktop Agent MAY implement outside the API, or whether they SHOULD or MUST implement new standard API calls that allow users or apps to do that...

[kriswest]

Do you want to try and fit in a quick a chat on this in today's meeting, or defer to a later one @robmoffat ?

[robmoffat]

From the last Web Browsers meeting, I was asked to try and justify why I think this would be a good change to the standard:

Although FDC3 recommends a set of user channels, I would like this to be controllable in Sail so that users can have channels for their own purposes. E.g. A user might want to create a channel called "EMEA" where they look at their EMEA stocks, or a channel called "Pension" where they open apps and do some analysis on their pension fund. Having channels just called "Red", "Green" etc. means that the user has to manage a mapping in their head between their assigned purpose of the channel and its colour.

Furthermore, FDC3 recommends 8 (I think) different coloured channels. This is often Too Many. As a user, I probably don't have eight different things on the go at once. Clearly, the reason we recommend this many is to accommodate people who do have lots of stuff happening, but for everyone else this is over-complicating things.

[kriswest]

Colour channels are a long established pattern in a multi-application environments in finance, enabling users to visually link windows they see on their desktop. All UIs I've seen demonstrated for channel based linking rely on colours for most users (with glyphs to support the colour-blind) as part of a compact control that is quickly visually assessed and the current set of user channel metadata is arranged around that, with the names and ids playing a supporting roll through the API.

What you propose seems to depart from the established use cases and we would need to assess whether there is consensus amongst the FDC3 community that we need to support this use case, whether that will constitute a breaking change (primarily for Desktop Agent vendors, but also app developers where they need to interact with a changing channel set) and on what API calls, events and DACP and bridging protocol messages need to be created - including whether it will be necessary or possible to agree sync of channels over the bridging protocol (which was specifically rejected/avoided the first time round by consensus). Further, Desktop Agent vendors that support saved layouts or workspaces etc. (terms vary as they are un-standardized but very common features) will also need to work through the implications for saved or shared layouts - including in situations where layouts are deployed to multiple users or shared between them (again this is relatively common). That in turn may necessitate bringing those concepts into the standard in some form (even if they don't have direct API support).

As this is potentially a significant (set of) change(s), I think it should be discussed through the Standards Working Group rather than any of the current discussion groups.

Finally, I foresee one alternative solution based on your use case (remembering a mapping of user channel to purpose), the ability to attach additional metadata to user channels - i.e. the channels don't change but you add an annotation to them that can be used as part of the UI. This could be done with or without API support (i.e. it could be a particular DA's feature or it could be a feature of the FDC3 API). API support could be as simple as an extra field on DisplayMetadata or also include an API to set the metadata (although its probably not for an app to do so, but the DA's own UI).

[kriswest]

P.S. I remember that we debated going with 6 or 8 channels when the recommend set was established. It was decided that we would go with 8 for future proofing - the was a consensus that a set that was too small for power user was worse than a larger set with some channels going unused.

[kriswest]

There is more detail on the discussions around the recommended channel set in:

• the issue: Add a recommended set of user channel definitions to the API #717
• the PR: 717 Add a recommended set of user channels to the Standard #727
• Bridging discussion group meeting minutes, including at least:
  • Desktop Agent Bridging Discussion group - 9th March 2022 #611
  • Desktop Agent Bridging Discussion group - 23rd March 2022 #628
  • Desktop Agent Bridging Discussion group 4th May 2022 #692