This is basically making a Rest API for FDC3 commands so should apply to to other things beyond protocol handlers. More than just standardizing taxonomy conventions.
Discussion points included:
Benefits of this approach over simply using http include enabling you to send a message from a web app in a browser to a desktop FDC3 agent. Could also be from a link in an email or Symphony chat. With http you get a blank chrome window whereas with a protocol handler you get more seamless interaction.
There are still some things to work out. E.g. desktops can set up their own protocol handlers (Symphony, OpenFin and Refinitiv do this or something similar) and owners of desktop environments can disallow creation of protocol handlers. Determining where specifically an FDC3 protocol handler would route to if there were multiple exe's, for example.
This is somewhat speculative for now and the group will carry on discussing. Reach out to Nick or Johan if you want to be involved.
Issues that are still open should be moved onto the combine repository.
Re-affirmed the new site fdc3.finos.org, where content is very close to where the group feels comfortable there is enough for a 1.0 FDC3 release.
Specifically for the As far as API WG - encouraged everyone to contribute to the effort, even proofreading is helpful. There is also a list of tasks and anyone can help get this done in the next couple of weeks.
Current target is 19th March. Flip to 1.0 but right now need to consolidate.
In terms of issues and PRs, we will use labelling and tagging to apply to say, API, Use Cases, etc. so that you can filter fro example.
Plan to have a blog post for go live.
Old repos will be archived.
Leslie asked about where demo versions should go and how to address commercial companies posting materials.
At a high level they have decided not to go live with reference implementations as part of the release but they will continue to have (satellite) repos with ref implementations, samples, etc.
5 min
AOB
group
AOB
Riko noted that high on his list for next work is context sharing, which you can do roughly with broadcast functionality in current API but it’s at a place to use and need something more like the Glue42 or Finsemble APIs to meet the kind of work they are seeing required at client sites.
General agreement from group that this makes sense and should be a focus area for the group to discuss.