2018-07-18 Meeting Notes

Attending:

Nicholas Kolba (OpenFin)

Anton Nikolaev()

Leslie Spiro(Tick42)

Philip Broadbent (OpenFin)

Riko Eksteen (JPM)

Svyatoslav Kryukov (DB)

Brian Schwinn  (OpenFin)

Espen Overbye (OpenFin)

Jonathan Teper (JPM)

Frank Tarsillo (Deactivated) (IHS Markit)

Agenda

No other AOB

Update with next meeting

Riko: Issue with GtiHub

- no engaging in repos, issues not followed up

- some of the comments (may 10’th) - no response

- want to check - are we encouraging issues?

Nick: yes, but we have some agreements that we have not moved to TypeScript

(Frank joined)

Update from Frank - App directory group

Joining this group to make sure we are joining forces.

Quick 10 mins

    2 proposals:

    1. Discoverability of the directories - will be approved

    2.Schema for app directory

    - Ignored authentication for now

    Initial schema from OpenFin(Nimit)

    Alternative from Tick42 - swagger (Open API)

    Has been discussed - and modified by Frank - interfaces created by Frank - https://github.com/FDC3/appd-api

    Yaml file on github

    Can be used to create language stubs - done on GitHub

Leslie: comment: we will have vanilla services that we can use?

Frank: jepp, we’ll stand up 

Brian: Do we have plans for stronger app identify?

Frank: Yes, but will be coming 

Brian: I`ll reach out

Nick: Good to see interaction

PR outstanding: (https://github.com/FDC3/API/pull/13)

Has been constructive comments to the PR

No minutes - finos helper disappeared 

Slava: feedback to PR (look at code)

    Purpose of the PR: we want to address specific point-2-point api (rpc style)

    1. Instances - for us to target an instance specifically 

    2. Formalizing the response object from the invoke method

    Error types added

    Not allowed to comment on GitHub due to policies

    Could not use the bot, only way for us to particicape is this calls or email

    Can not use anything that does not go through survelliance (only email / symphony)

Nick: good clarification, was not clear, does other have problems with participating?

    We can create a specific email group linked to PR for 

Slava: unfortunate that we cannot participate

Nick: I`ll setup a specific group to discuss

Colin: You cannot use the Symphony bot, where is the problem?

Sla: we have asked for feature, but currently only can comment on top level, not in the code

Sla: I can go through specifics, Nick?

Nick: lets talk about the key themes not the details: app instance direct access, formalize return, merge open and invoke(?) API

Leslie: open q: fdc3 benefit from a more fully featured API (rpc, streaming ..)

Nick: 800 pound in the room - there is a wide specter from fire forget to streaming rpc

Brian: we need whats defined, but could be a rabbit hole, rpc could be a separate API

Nick: we could define a tighter layer (rpc) on top - who wants to discuss?

Raise of hands - + 3

Leslie: can we have a defined of : RPC is tight coupling

Nick: my def: app a and app b, app a has a ..  (Nicholas Kolba - need clarification here)

Leslie: in glue42 - we talk about request / response, having governance for common set of verbs, everything we see for intents 

Brian: firing of intents - you are not calling endpoints - but you are asking someone to handle, looser coupling by design

Nick: everything you are specifying is in line with FDC3, we are very much on the same page

Riko: Intent is something you want another app to do -> it is implicit fire and forget, and not RPC

    RPC is valid, but should not use intents, but different things

Leslie: Agree - should be another api, not intent (that is fire/forget) - rpc should be something else

Nick: other systems with intents have return values, rico, should FDC3 support rpc?

Riko: yes, but intents should not solve, it is one brick 

Brian: agree with rico

Nick: you are raising to any app that can fill an intent

Brian: but after knowing that an app can fulfill, you can do rpc?

Nick: but can also be “resolveSymbol”, don’t need to do RPC

Riko: fine with “resolveSymbol”, but it is not an intent to move, will use looser vs tighter contract: tighter when expecting something specific back

    More complex intents 

Colin: most will expect something back - at least 200 (ok)

Colin: examples?

Leslie: with symbology, key is response

Leslie: do we have a definition that we can use to be higher level rpc on?

Riko: Intent WG ref: let us create workflows on the fly - not response, but invoke on the fly, don’t need response

Brian: Symbology use cases should be thrown out (rabbit hole)

Nick: maybe symbology is not a good example

Slava: point with PR is keep intents (fine in pre trade space) - but for post trade need rpc

- extending the API to solve more use cases

Nick: 3 mins - wrap up discussion

Brian: I forked with return types, can show

Slava: we have already described in PR, we should use Use cases

Riko: can we go back and look at the full API we would need for interop

Nick: We need to nail down scope and terminology, intents vs rpc etc. each level will need decisive

- Brian can you make your fork available

- Socialize through mailing list

- We need to conclude to continue, good discussions, please all - dig into and we can reconvene on the proposals

- Lets dig in and try to move the discussion forward

Leslie: Nice to have desktop agent architecture, and move use cases WG forward

Nick: we know that real systems will need all the APIs, but where does FDC3 stop?

Riko: last q from me: recording so that we all can participate

Nick: good idea! - we need records, but we also need other forms for communication - email/github/

Riko: hard to note and participate

Espen: jepp

Colin: if only high level notes, doable

Nick: the majority of the work should happen outside of the meetings

- we’ll convene in 2 weeks time, intents & rpc and other API’s & clarify direction

Espen: Note to all - check to make sure I have gotten the above more or less correct, diverging discussion, hard to get all details.