Desktop Agent Bridging Discussion group 24th April 2024

kriswest commented 2 months ago

Group overview

Discussion group devoted to 'bridging' between FDC3 implementations (aka Desktop Agents), allowing applications running on one Desktop Agent to integrate with FDC3 applications running on additional Desktop Agents and devices for the same user.

Desktop Agent Bridging was added to FDC3 in the 2.1 release as an @experimental 5th-Part to the Standard. The group is now dedicated to the discussion of implementations, Q&A on the protocol, and working to improve the protocol further.

Relevant issue tags

Issues that relate to Desktop Agent Bridging bear the label:

Meeting Date

Wednesday 24 April 2024 - 9am (US eastern timezone EDT) / 2pm (London, BST)

Zoom info

Join Zoom Meeting
Meeting ID: 969 4029 4948
Passcode: 636931

Dial-in:	Country	International Dial-in
US	+1 929 205 6099 (New York)	877 853 5247
UK	+44 330 088 5830	0800 031 5717
France	+33 1 8699 5831	0 800 940 415
Find your local number	https://zoom.us/u/ad2WVnBzb8

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 legal@finos.org 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.
A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.

Participation Requirements

Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.

Please click the following links at the start of the meeting if you have not done so previously.

View the CSL
View the GOVERNANCE of the Project
Click here to start a PR.
- Edit the page to add your details.
- Hit the save button.
- Click "Create Pull Request".
- Click "Accept" on the EasyCLA dialog in the PR's discussion section.
Click here to send email to become a voting participant on the FDC3 Project

Tracking Attendance

Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.

Agenda

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- [x] #1176
[x] Testing Bridging implementations - contribution of tests
- Overview of test project
- Fork it, implement a BridgeFactory for your bridge and run!
- Testing a native bridge implementation
- BridgingZodSchemas for message validation and how to generate them.
[x] Updates from the BackPlane project
[x] Building language adaptors via bridging @robmoffat
[x] AOB & Adjourn (5mins)

Minutes

@john-ciq provided an overview of the work so far to contribute interop.io's tests for a Desktop Agent Bridge to FINOS so that they can be used by the Backplane project and other implementors (tests are for the Bridge implementation rather than a Desktop Agent connecting to aa bridge)
- Currently, there are two projects - one containing the tests and another containing a template app for running the tests that you customize to run them against your own Bridge implementation.
- These will be merged into a single project to ensure that you can simply fork that project, customize one file and then run.
- You need to customize the BridgeFactory class to implement start() and stop() functions that are used to manage the bridge life cycle (start/stop) during the tests.
  - To work with a non-js implementation, where the bridge needs to be started as a separate process to the tests, use node's child_process.spawn() function and subprocess.kill to implement start() and stop().
- A recap of how the tests themselves work was also provided.
- A 'Test client' class is used, which can connect to the web socket, send predefined messages, wait for specific types of message in response and finally can return messages received.
- Multiple test clients are setup and made to connect to the bridge, then predefined messages are sent and then responses compared to predetermined 'correct' responses (after overriding timestamps and UUIDs within them).
- The Jest configuration can be overridden as needed
- @kriswest noted that Bridging supports a port range, but the tests currently declare static port - this should be moved to the example/BridgeFactory to ensure all settings are configured in the same file
- Message schema validation tests have been explored, but are not currently in the set that run. The necessary technology is implemented, but individual tests need to be written. These slightly duplicate the Message protocol tests (as they would test each individual flow) but instead of checking functional behavior would confirm messages validate against their schemas.
- A coverage report can be produced as part of the tests - this is only expected to work for node.js bridge implementations running in the same process as the tests. An issue was noted during the demo which will need to be correct (was checking coverage in tests rather than bridge source code).
Some discussion of the current status of the Backplane project was held
- @Vivek-NatWest is currently the sole maintainer and is lacking hours to contribute - support is needed to recruit additional maintainers.
- The connection flow is implemented, but messaging flows still need to be adapted to the standard.
There was some discussion of how and why to implement language adapters for FDC3 using bridging (Backplane includes that feature via >NET and JS clients it includes).
- Allows an existing, monolithic application to be integrated with FDC3-enabled apps running under another Desktop Agent, without the significant restructuring and reintegration that is often needed to adapt a monolith to FDC3. I.e. its a shortcut for apps that firms don't wish to invest in significantly (often because they plan to replace them with FDC3-enabled micro-frontends and prefer to invest their effort there until the older apps can be end-of-lifed).

Action Items

[ ] @john-ciq merge the test project and example project to simplify usage to fork, customize, and run of a single project. Implement a README file describing what you need to do.
[ ] @john-ciq Tweak the test projects so that the bridge port can be set in the same place as the BridgeFactory (currently hardcoded in the TestClient
[ ] @john-ciq Fix test coverage report - if it can report its possible to report on an external project (might require linking?)...
[ ] @john-ciq & @kriswest When the above changes are complete, make the test repo public (request from help@finos.org) and contact @Vivek-NatWest to arrange time to try the tests out over the BackPlane project.
[ ] @kriswest Attempt to recruit participants for the Backplane project at the next Standards Working Group and maintainers meetings