Channels, Feeds & Transactions Discussion group meeting 12 Aug 2021

[kriswest]

Group overview

There are currently 11 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 12 Aug 2021 - 9am EST / 2pm GMT

WebEx info

• Meeting Link
• Meeting number: 127 111 4958
• Password: e3EeiZkzF25

More ways to join

• Join by video system:
  • Dial 1271114958@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: 127 111 4958

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 (5mins)
• Review action items from previous meeting (5mins)
• Make it possible to return data from a raised intent #432
  • Review alternative proposals @mattjamieson (25 mins)
• Clarify how apps should handle broadcast and receipt of multiple context types #434 (discuss - 10 mins)
• Add the concept of a feed or stream to FDC3 to handle use-cases not covered by channels or intents #433 (solicit proposals for next meeting - 5 mins)
• issues that need PR authors (5mins)
  • All DesktopAgent and Channel APIs should be async #362 (minor API changes)
  • fdc3.joinChannel docs should explain expected behavior on joinChannel #418 (Documentation only)
  • Rename 'System Channels' 'User Channels' #430 (Mostly documentation, some small API changes)
• AOB & Adjourn (5mins)

Minutes

• @mattjamieson recapped proposals for Make it possible to return data from a raised intent #432 and introduced an alternative proposal based on intents in Android: Make it possible to return data from a raised intent #432 (comment)
  • @mattjamieson commented that working through the alternative proposal made him prefer option 2 from the original proposal
  • Discussed how option 2 from the original proposal can tell you if the handler has finished processing, even if not returning a result (data promise resolves with void or data)
  • data property being a promise is quite uncommon
    • consider replacing with a getData() function that returns the promise? which is similar to that alternative proposal
  • How do you know that an intent returns data? To be useful you need to know in advance.
    • appD provides a metadata structure (already describes what type of contexts does an app support for an intent). This could be extended to describe return types
    • Its weird as a developer to not know in advance what type is going to be returned...
      • findIntent and AppIntent might be extended
      • Intents have very little definition currently
  • Do these proposals introduce complexity that will slow uptake of the standard?
    • @kriswest & @rikoe: The current proposals introduce a fairly limited extension to the current standard, which follow similar patterns from other standards (e.g. fetch API in javascript). Any additional complexity is on the Desktop Agent implementor or apps that want to use the additional option (and that burden is lower than if we introduced additional concepts OR left the app developers to sort this out without standardisation)
  • The group expressed a preference for
    • not adding additional functions to the standard where possible
    • updating option 2 to replace the data promise with a function to retrieve that promise
    • (possibly) extending raiseIntent/findIntent to allow expressing a desire for particular return type(s) (+ appD extension to provide that data)
    • reviewing more proposals!
      • with usage examples!
      • @pbaize proposed an alternative based on combining existing concepts, but wrapping them to solve for the usecase (e.g. raising an intent with a context type that includes a response channel name and/or request id, receiver connecting to the channel and sending the response)
        • was noted that we currently have no way to clear up channels so this may cause them to proliferate...
        • would need request/response context types to be created

Action Items

• @kriswest Raise PR for Rename 'System Channels' 'User Channels' #430
• @kriswest Raise PR for Make optional: fdc3.joinChannel and fdc3.leaveChannel #431
• @kriswest Raise PR to improve spec and documentation of fdc3.addContentListener to mention joining channels
• Raise further proposals (with usage examples) to resolve: Make it possible to return data from a raised intent #432
  • @thorsent @kriswest Update option 2 proposal to convert the data element in the resolution into a function, modifying raiseIntent signature
  • @pbaize to work on an alternative proposal based on wrapping existing concepts
• @kriswest Next meeting agenda:
  • First (been bumped twice): Clarify how apps should handle broadcast and receipt of multiple context types #434
  • Further work on Make it possible to return data from a raised intent #432
• ALL: volunteers needed to create PRs for the following issues:
  • All DesktopAgent and Channel APIs should be async #362 (minor API changes)
  • fdc3.joinChannel docs should explain expected behavior on joinChannel #418 (Documentation only)
  • Rename 'System Channels' 'User Channels' #430 (Mostly documentation, some small API changes)

Untracked attendees

Full name	Affiliation	GitHub username

[ggeorgievx]

Present ✅

[thorsent]

Present

[Julia-Ritter]

Julia // FINOS

[jgavronsky]

Jane @finos here

[mattjamieson]

👍

[rikoe]

present

[kriswest]

Present

[pbaize]

Present