Channels, Feeds & Transactions Discussion group meeting 14th Oct 2021

[kriswest]

Group overview

There are currently 9 open issues in the FDC3 repository, under consideration for the 2.0 release, that relate to the existing concept of channels (both the 'system channels' used via the desktop agent API, and 'app channels' interacted with through the Channels API) and new concepts we've discussed introducing: transactions (a standardized way to make a request and receive a response back) and feeds (a standardized way to request a stream of data, such as a pricing stream).

Relevant issue tags

Current open issues that relate to the above concepts with the label:

Meeting Date

Thursday 14 Oct 2021 - 9am EDT / 2pm BST

WebEx info

• Meeting Link
  • Meeting number: 2700 235 4634
  • Password: 4eZpzMTm7J6

More ways to join

• Join by video system:
  • Dial 27002354634@finos.webex.com
  • 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: 270 023 54634

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. As such, participation in a Discussion group is not required for contributing to any particular issue or FDC 2.0 as a whole.

Agenda

• Convene & roll call, review meeting notices (5 mins)
• Review minutes & action items from previous meeting (10 mins)
  • Channels, Feeds & Transactions Discussion group meeting 30th Sept 2021 #465
  • Note adjusted meeting dates (28th Oct -> 4th Nov)
• Add the concept of a feed or stream to FDC3 to handle use-cases not covered by channels or intents #433 (20 mins)
• Allow intents to be targeted at specific instances of apps #450 (20 mins)
  • include discussion of Ability to open an application via intents in a pre-defined location #332
• Next meeting agenda, AOB & Adjourn (5 mins)

Minutes

• Add the concept of a feed or stream to FDC3 to handle use-cases not covered by channels or intents #433
  • Recapped previous discussion (Channels, Feeds & Transactions Discussion group meeting 30th Sept 2021 #465)
  • @thorsent related some thoughts on using raiseIntent to implement the request for a feed (raiseIntent returns a channel instance)
    • Return a context object describing a channel that will provide the feed (relating to the context in the request, e.g. pricing for AAPL)
    • Or another optional parameter on IntentResolution for the Channel returned.
    • @rikoe This makes that set of functionality possible with raiseIntent analogous to many server implementations we do fire and forget / request response / request a stream
    • @pbaize could we implement something, inside the FDC3 repo, from existing concepts that will work over any FDC3 implementation?
      • Could then go in the FDC3 NPM module
    • @kriswest doesn't deal with identity issues - anyone could join the channel and spoof messages
      • @rikoe Intents provide 1:1 communication - if you could only join this channel through the raised intent, rather than by name as at present, we can have 'private' channels that would ensure identity
      • @kriswest We would need a new API call to create a private channel (unnamed)?
        • Perhaps an extension to raiseIntent to request a response channel and addIntentListener API calls to receive one created by desktop agent for you
          • Puts the onus on the requesting side to flag that a channel is required and doesn't allow channel re-use
      • Could be mocked using existing API to be later refined via additions to the API
    • @thorsent Unless the client creates the channel is already listening to it, we still need to know when they join the channels (sync issue - if data sent before they listen it may be missed)
    • @thorsent We also need to detect disconnects/terminations to stop streams
      • @pbaize Should that be the responsibility of the Desktop agent?
        • The app/server will want to know that no ones listening - there will need to be a notification back to it, which means an extension to the API again.
    • @rikoe All this makes me think of RxJS and observables
    • @ggeorgievx Plex has a concept of subscriptions that fulfills these requirements
  • Group resolved to revisit at next meeting and prepare/review some possible solutions
    • @ggeorgievx Provide overview of plexus subscriptions
    • @kriswest & @thorsent to throw together a possible API proposal
    • @pbaize to try and put together an example using existing concepts

#450

• limited time to discuss
  • @pbaize reiterated a desire to allow instance id info or datastructures (within AppMetada) to be implementation specific
    • you use whats been returned to you by the desktop agent and don't need a specific structure
    • @kriswest we'd still need to standardize where the implementation-specific info goes in the (AppMetadata) object
      • There are also two uses: returning a list of instances and specifying a specific instance, where, an array may not be appropriate
        @pbaize to post on issue with some ideas/refinement to proposal
  • @kriswest flagged Ability to open an application via intents in a pre-defined location #332 conflates targetting an existing instance and where to place a window that is spawned by a raised intent/open
    • Strong desire to avoid starting to handle windowing through FDC3 from most participants in the meeting!

Action Items

• @kriswest Next meeting agenda:
  • Continue the discussion on:
    • Add the concept of a feed or stream to FDC3 to handle use-cases not covered by channels or intents #433
      • @ggeorgievx Provide an overview of plexus subscriptions
      • @kriswest & @thorsent to throw together a possible API proposal
      • @pbaize to try and put together an example using existing concepts
    • Allow intents to be targeted at specific instances of apps #450
• @pbaize comment on proposals for Allow intents to be targeted at specific instances of apps #450 with ideas for how to specify instance identity (running instances and specific instance target) in implementation-specific way
• Rolled over from previous meetings:
  • @rikoe Raise an issue for adding TS generics to FDC3 APIs
  • @rikoe Split out separate issues for raiseIntent with data return type for other API extensions, and declaring return types in AppD intents
  • (needs PR author) Rename 'System Channels' 'User Channels' #430
  • @kriswest Make optional: fdc3.joinChannel and fdc3.leaveChannel #431 (Documentation only)
  • @kriswest / @thorsent Make it possible to return data from a raised intent #432 (Create PR for final proposal @thorsent posted)
  • (needs PR author) Improve spec and documentation of fdc3.addContentListener to mention joining channels #451
  • @pbaize All DesktopAgent and Channel APIs should be async #362
  • @kriswest @rikoe Discuss experimental features (stage 1/stage 2) in terms of spec rewrites with LF team

Untracked attendees

Full name	Affiliation	GitHub username

[Julia-Ritter]

Julia // FINOS

[agitana]

Aitana Myohl / FINOS

[pbaize]

Pierre Baize // OpenFin

[kriswest]

Kris West // Cosaic

[rikoe]

Riko // Adaptive

[thorsent]

present

[ggeorgievx]

Present ✅