FDC3 Standard WG Meeting - September 22nd, 2022

Date

Thursday 22 Sept 2022 - 10am EST / 3pm GMT

WebEx info

Meeting Link Meeting number: 665 568 411

More ways to join

Join by video system:
- Dial [email protected]
- You can also dial 173.243.2.68 and enter your meeting number
Join by phone
- +1-415-655-0003 US Toll
- +44-20319-88141 UK Toll
Access code: 665 568 411

Meeting notices

FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact [email protected] with any questions.
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from the previous meeting (5mins)
- #802
[x] FDC3 conformance framework demo and progress report (15min)
[x] Contribution opportunities and an update on Desktop Agent Bridging (5 mins)
Discussion of open issues (25 mins) (will not get to all, the remainder to roll over to future meetings):
- [x] #807
- [x] #820
- [ ] #242
- [ ] #301
- [ ] #559
- [ ] #563
- [ ] #735
- [ ] #386
- [ ] #387
- [ ] #564
[x] AOB & Adjourn (5mins)
- Please raise issues for any topic that you'd like discussed at future meetings.

Minutes

A number of incomplete action items were rolled over from the previous meeting minutes.
Conformance framework
- Conformance framework repository: https://github.com/finos/FDC3-conformance-framework
- A demo of the framework and commentary on the implementation was provided
  - There are set-up steps that may vary by desktop agent/container implementation (several apps need to be added to the container, as testing FDC3 compliance requires communication between multiple applications)
- The Framework is ready for testing and review, prior to starting a process of adoption as an official conformance test
  - @kriswest When adopted, a pre-built copy of the framework can be served from the FDC3 website (toolbox folder) to make it easier to run/ensuring that there is an official copy to run from a URL.
  - @lspiro-Tick42 will get someone to review conformance framework against Glue42
- It is intended that Desktop Agent vendors will be able to regularly run the tests against their products to ensure compliance
  - Adoption and maintenance of the tests will also necessitate some collaboration by Destkop Agent vendors in reviewing and feeding back on the tests.
- Initial test runs show some small amount of deviation from spec from all 3 vendors, but only at the edges (particularly error responses)
  - Error responses were poorly documents in FDC3 <= 1.2, there are still ambiguities in the 2.0 documentation
Contribution opportunities
- There are a number of maintenance tasks that need doing in the FDC3 repository, which are now marked out with the 'good first issue' tag: https://github.com/finos/FDC3/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
- We're seeking volunteers to help resolve these - which is an opportunity to participate or work towards becoming a maintainer.
Update on Desktop Agent Bridging
- Proposal is close to complete first draft (based on a standalone bridge that Desktop Agents connect to in order to relay comms and support interop between apps under different Desktop Agents and across different machines)
- NatWest Markets have begin the process of contributing a software project that will serve as a base for a bridge implementation: https://github.com/finos/community/issues/204
- A demo will be provided at the next Desktop Agent Bridging discussion group meeting on 28th September (2pm BST / 9am EST
Discussion of open issues
- #807
  - As FDC3 API calls are async they return reject promises rather than errors
  - However, Desktop Agent implementations are sometimes rejecting with the relevant String value from the error enumeration, rather than a javascript Error object
    - This is inconsistent between implementations which will lead to additional complexity in code that needs to handle those errors
  - Rejecting with an Error object is preferred as this can confirm more information, including a stack trace (from the point at which the error was thrown)
  - The documentation is not particularly explicit about rejecting Error objects and maybe self contradictory in places.
  - Participants agreed that it was always intended that Error objects are rejected, rather than strings and that this needs clarifying in the documentation
  - It was further agreed (by silent consent) that a clarification should be added to the 2.0 version of the Standard (rather than future 2.1) as it would not constitute a change.
- #820
  - An overview of why API calls based on the name field were deprecated in FDC3 2.0 was provided
    - name is non-unique within a directory and cannot be fully qualified to make it globally unique.
    - appId has neither problem
    - switch to AppIdentifier type as preferred input to those API calls also enables them to address app instances, and in future, other desktop agents across a bridge.
  - The name field remains required in AppD records and may continue to cause confusion (its role is often confused with that of the title field.
  - The issue proposes to make name optional in an appD record and to deprecate it (ensuring that developers are discouraged from using it)
  - It was further proposed by @hampshan and seconded by @kriswest that title is promoted to required, ensuring that a display name is always available for an app
  - Silent consent was sought and received to make the proposed changes.
- #242
  - A brief overview of a use case was provided
    - Sales traders may be working 2 or 3 clients or orders at once and have multiple copies of certain components on their screen, grouped into separate channels.
    - They may also have single copies of other apps (due to screen real estate constraints or because those apps need to be singletons) and need these to react to several different groups of components/channels
      - Generally those apps will not be publishing, but just listening.
  - @kriswest reported that this use-case has been report by several different clients who have been using mutliple-channel membership in production for a number of years.
  - The end of the meeting curtailed discussion; It was requested that participants review the use-case ready to discuss at the next meeting.

Decisions Made

#807 can be resolved in existing standard versions as it doesn't constitute a change, only a clarification of what was intended.
#820 name should be deprecated in appD records and title made required.

Action Items

[ ] @kriswest prep next meeting agenda to include next issues on list
- Including revisiting #242
[ ] @kriswest or volunteer: raise a PR to resolve #807 by clarifying (in the 2.0 version of the documentation) that FDC3 API calls the result in errors should reject with an Error object, rather than a String.
[ ] @kriswest or volunteer: raise a PR to resolve #820 by making name optional and deprecated in appD records and making title required.

Rolled over from previous meetings:

[ ] @hampshan Review appD 2.0 record properties and raise an issue to add a link to an app's help documentation (if the moreInfo link is not sufficient). This might be used, for example, to add a help link to window chrome in a desktop agent.
[ ] @kriswest or volunteer: raise PR to resolve #719
- Add optional/recommended API endpoints for /intents and /contexts to the appD API.
[ ] @kriswest or volunteer: raise PR to resolve #312
- deprecate interop.intents.listensFor[<intentname>].displayName field in appD and AppIntent.intent.displayName in the API types and add explanation of using intent name for display to documentation.