Create an AppD reference implementation

[kriswest]

Enhancement Request

It is advisable that any standard provide a reference implementation that may be used to confirm or compare the expected behavior of an implementation of the standard and/or be used as a base for other implementations. The AppD is one such standard and it is likely that the provision of a usable reference implementation will help drive its uptake throughout the financial services desktop software community.

In the past, a java implementation of the AppD was provided at: https://github.com/FDC3/appd-poc. This is not currently maintained, nor included in the FDC3 repository. Reviving this implementation, or providing a new one (ideally based on Node.js) is desirable.

Use Case:

• Reference implementations may be used:
  • directly, saving a firm from implementing their own AppD
  • as a starting point by firm implementing their own AppD
  • as an example of expected behavior from AppD.

[amanjmd]

Hi @kriswest ,

I am working on the reference implementation for the App directory in Java and spring boot . I had a query regarding the user channels.

• Do we need the user channels to be persisted to App directory corresponding to the user .
• Also , in the documentation here , it was mentioned that an application can be joined to a single user channel . Hence I was not able to understand , what should be the value for the user channel field in the application json response , as it could be different for different user.

[kriswest]

Hi @amanjmd user channels are joined at runtime via the Desktop Agent API. The role of the app directory is simply to describe an app's capability of using those channels at runtime, providing details on what context types they'd listen for and broadcast in theinterop.userChannels.listensFor and interop.userChannels.broadcasts elements. At present this information is purely to inform users and developers, however, it could also be useful for an AI to understand app capabilities or for a desktop agent or app directory UI to propose apps that interoperate with other specified apps.

Regarding persistence of selected user channels, this is often a feature of desktop agents when saving a workspace or layout - that's a feature not covered by the fdc3 standard but common in implementations. You wouldn't save the selection to the app directory but to some other store for layouts that includes instances of apps from the directory.

[amanjmd]

hi @kriswest ,

Where in the repo , we will be keeping the reference implementation , considering implementation can be in multiple languages

[kriswest]

@amanjmd during the hackathon kickoff we recommended that implementations are first created in their own respository and submitted as part of the hackathon - I'd recommend doing that whether you are contributing as part of the hackathon or independently. The FDC3 project may then move to adopt one or more implementations as reference implementations, perhaps moving them into the FDC3 repo's /toolbox directory or otherwise linking to them in their own repositories.

There is another huge PR in flight at the moment that refactors the structure FDC3 respository which we need to complete before adopting anything - @robmoffat and others are working on that as we speak.

[amanjmd]

hi @kriswest

Sure . I totally understand on the workload this hackathon would have put on .

As suggested , I have done the implementation here

Let me know in case any thing else is required to be added ,or in case my understanding is not aligned with required implementation . Will do the required modifications.

[ThatNinjaGuy]

Hi @kriswest

We have created a generic solution for appD. This NodeJs app attempts to give the core functionalities of authentication, authorization, app definition storage, app search and metadata access/update per the definitions of FDC3 enabled applications. To improve the ease of usage, a dashboard has been created to allow users to approve subscription requests to appD, view and edit application details adhering to rhe FDC3 standards. This serves as a management center for AppD.

Our attempt has been to focus on extensibility so that organizations don't need to create a fresh implementation for consumption but can be ready for consumption in a very quick time and add custom features as required with decentralized design.

Reference to our entry through the discussion-> finos/community#331 (comment)

More details can be found at our implementation: https://github.com/kushagraGit/finos_hackathon_citi_vikings

This is part of the #FINOS-Citi Hackathon. Our team members are:
https://github.com/kushagraGit
https://github.com/Yousuf-Ejaz
https://github.com/ThatNinjaGuy

Our original entry was through the discussion but putting it as well for completeness.