Refactoring / Multiple Sub-Projects

[robmoffat]

@sebbenmbarek and I were chatting today about how to factor-out Electron FDC3. We're thinking along the lines of:

FDC3 Bus

• Implements the DesktopAgent API, handles Context Data / Intents etc.
• Plugable (Servlet-style) middleware layer so that we can interact with the other layers.

Skeleton App

• Super basic app that I can build / run within the desktop and see how things work.
• Easy place to hack on top of.

UI / Window Management

• Could be based on/look a bit like Ferdi (also: https://webcatalog.io)
• Seb's Golden Layout ?

Electron

• Handles all the concerns of doing the Electron Framework, including memory management stuff I guess
• Alternatively we could base a UI on something else like deno or Tauri?

SaaS?

• Would be nice to run the whole thing in a browser and not use Electron at all.

App Directory

• Could be run on localhost via a command, or using the FINOS AppDirectory

Ideally, all of these should be sub-modules in the repo.

Developer Experience

1. Play With FDC3.
   • Download, run, build locally with some example apps.
2. Developer tools built-in
   • FDC3 workbench goes in this direction
   • A middleware logger layer that shows you exactly how things are being processed / work
3. Wrap an existing app
   • Say GMaiil (?). Point to url, run in the container
   • Point to an existing url and run it in a container
   • Create an FDC3 AppD record from a URL
   • I want to add some stuff to the app directory to try out some arrangement of apps.
   • "I already have this running on X, but I want to try this in Electron FDC3"
4. Build a new app4.
   • We need some examples to hack on. e.g. Nicks existing apps
5. Use one layer in your own app
   • E.g. symphony (for example ) using this OSS FDC3 bus implementation)

Demo

What do we want to achieve in NYC? We've seen lots of demos where we have interop between two or more different apps. What's the "next level"?

The story could be the Dev UX?

• Visualisation of the bus
• How to put this together from a developer standpoint
• Can we show the developer learning curve being really easy?

[nkolba]

@robmoffat ++ need for more dev tooling including example/hackable apps and things like visualization of the interop state (the bus)

Re: splitting out logic into FDC3 and "Electron" (what we might call runtime). This is a big undertaking. Current refactoring prepares the stage for more of a split, but to get there we'd need to define (and then implement and maintain) a full API for the runtime layer that the FDC3 layer would use exclusively to interact with anything specific to Electron. This would include windowing, IPC messaging, and anything specific to the "runtime" environment of the project (i.e. tabs in the windows, the search UI feature, etc). High level steps to get there are going to be:

• refactor of code to support modularization of business logic (in progress)
• test out with 2.0 / 1.2 support (i.e. swappable versions at build time)
• identify use cases / stakeholders for a split into actual layers (e.g. a stakeholder who wants to use just the FDC3 business logic or swap out Tuari for Electron)
• create the split with that use case for validation

[robmoffat]

Re: splitting out logic into FDC3 and "Electron" (what we might call runtime). This is a big undertaking.

Yeah, I've been looking at the code again today and I agree. A lot of effort rn, given the amount of time we have.. we could pick that up later?