2018-09-04 FDC3 General Meeting - Meeting Notes

Table of Contents

Date/Time

2018-09-04 10am US-Eastern

Attendees

NameOrganisation
OpenFin

Outstanding Action Items

  • Group: Fill gaps in confluence page
  • Nicholas Kolba: Start sending reminders about working group meetings
  • Group: This meeting will happen again in on July 10, let Nicholas Kolba know if there is anything to add to agenda

Agenda

TimeItemWhoNotes from the Meeting
5 minConvene & roll call
10 minReview action items from previous meetings (see above)


10 min

New Participant Intros

  • new participants in FDC3 and new attendees to the meeting introduce themselves
    • organization and role
    • why is interoperability important to you / your organization?
    • what do you hope to accomplish with FDC3?
Group, Nicholas Kolba coordinating


30 min

Working Group Updates

  •  API WG
  • App Directory WG
  • Context Data WG
  • Intents WG
  • Use Cases WG

Nicholas Kolba

Espen Overbye

Tim Kolecke

Frank Tarsillo (Deactivated)

Former user (Deleted)

Jonathan Teper

API

  • The past 4 weeks of August has been a slower cadence than we should see i the coming weeks.
  • Has been going back and forth with some fundamental questions on the scope and standards.
  • PR has been approved although the spec hasn’t been fully approved.
  • Highlights are to try to make clear how one can build a more tighltly coupled RPC system on top of the standards/ Intention.
  • There is an idea of hte desktop agen that exposes the FDC3 API to the app nd fulfills the interop functionality on behafl of the app. It will connetct ot one or more app directories and multiple agents. Will resolved intents, launch apps, context data. Most of what needs to be standardised are the interfaces.

Context Data

  • Tim - Had our first context data mtg two weeks ago. Had discussions around how you can use context data, how you can assign particular types. Have some examples but not actual specs. Specifying what an FDC3 vs Other context would be and give some examples.
  • Riko: Not sure where it fits. What is interesting - is there a way to centralised. Do we need a registry of types? Where you store the types, shape of them, e.g. where does a contact live, what does it look like, how do you suggest a new field?
  • Nick: It’s a fine line there between context vs object modelling (which is part of FO). We still need to work closely with them
  • Leslie: One thing I have proposed is that there might be, e.g. 3 different copies of the context data describing the client differently (symphony, proprietary, Tick42) - can be different types or different identifiers (email address, symphony identifier, twitter handle, etc.)
  • Good topic and there will be continued discussion.
  • Explore how to assign multple contexts -- mixed types … will it be tied with multiple identifiers
  • Differentiation what an FDC3 contact might look like (and how that compares with Symphony)
  • Riko ( JPM): Is there a need to centralize how the context that participate in the interop that participate
  • Tim: Context is what came up due to the lowest common demoninator -- but as far as finanical onbjects, or the payload and the data, that would be the work of the financial objects working group (sic) [I think they mean the Financial Objects program]
  • Nick: Can do this through different type, but also through different identifiers -- idea is that you can have any number of identifiers. One thing that would be valuable would


Intents WG Update

Nick to give update for Espen.

There is a proposal for initial set of intents and schema visible in GitHub. Waiting on some feedback from Use Cases and API WGs.

It will start up again in a couple of weeks.

Reach out if you have interest.

Purpose of intents is to create definition and schema of common intents in FDC3. You can see material in GitHub.

Leslie: The AppDirectory says I can publish these intents and tends to specify context API. General idea is that an intent is invoked with a context and that they work closely together with


Use Case WG

Kat gave here update

  • We’ve been going through both what is a use case as well as the governance of approval
  • 3 stage process, everything managed in confluence
    • Ad hoc
    • Submitted for approval
    • Approval / Rejected
      • Approval → discussions with relevant use cases; flesh out which WGs need to be involved
  • Acceptance guidelines
    • How a long discussion of this
    • What personas (actors) should we include -- e.g., do we include a CTO in this?
    • Decided to do a couple technologists use case to start
    • Initial traunch of use cases -- then there will be a vote after the meeting on Thursday; anyone who comments can vote on accept or reject on the initial set.
    • We are not going to manage it like this going foward (they will do ad hoc, not by set)
    • JT: this is really exciting -- to be asking “is this valid?”, “Is this useful?” -- it is important the people evaluate against a set of criteria -- we are asking participants to review against a set of criteria … vote will happen by email following the call and then close on Mondy



20 minAOB & adjourn

Group, Nicholas Kolba coordinating


Decisions Made


Action Items

Need help? Email help@finos.org we'll get back to you.

Content on this page is licensed under the CC BY 4.0 license.
Code on this page is licensed under the Apache 2.0 license.