¶ Return value in case of success
Return NULL_VALUE. That's what all the standard adapters return when there is no error nor any return value to return.
¶ Wireframe
What we call the 'wireframe' is the set of standard behavior all orchestra adapters implement.
¶ First version (wip)
The wireframe does three things:
- Handle the handshake with the Mount adapter
- Serve the declaration of the interface of the adapter
- Provide a way to log to stdout using the standard log format, which is the same as J Smart's adapter log format, which looks like that
I|2024-08-01 06:43:52.49 this is the message
¶ Handshake with the mount adapter
The wireframe invokes the mount adapter giving it's interface. From there, the mount adapter creates an outlet if it's a new adapter, or re-uses a previously created outlet if the adapter already has instances running.
We might decided to not accept mounting multiple different version of the same adapter if we wish to do so, not sure.
The mount adapter then returns the outlet the adapter should adapt on.
The mount adapter will act as a DNS from the name of the adapter to the outlet it's invoking on, that way clients don't need to maintain their own table of outlet EUID, they can just get the EUID of an outlet they're interested using their name.
¶ Declaration of the interface of the adapter
See https://gitlab.com/groups/ledr/-/wikis/home/Core/Platform/Standard-Adapter-Interface
¶ Future iteration of the standard
- Define standard event in the lifecycle of the adapter, such as startup, request received etc... that should triger a specific log message, so we can do analytics by reading the logs such as how busy the adapter is, how fast does it respond etc...
¶ Other concerns
We seem to agree that we don't want logs to be managed by the adapters themselves through the wireframe, because we typically have multiple instances of each adapter and one instance can't provide the logs for the other instances. Instead we'll have a "system adapter" which will have the ability to query the logs of all instances and return them as once. It will just use docker to get the equivalent of a docker compose logs <adapter>.
There is still no consensus about what the mount adapter should exactly do. The mount adapter is kind of like a DNS service whose job is to create outlets for adapters to adapt on, and anyone can query the outlet of an adapter by using a friendly english name like "google-search". This allows us not to hard-code outlet's entity ID in every program that need it, instead we hard-code the friendly english name which is less likely to change.
In Geoffrey's implementation (often called "neomount"), the mount adapter is also responsible for storing in the outlet's avial model the interface of that adapter, as advertized by the adapter itself during its declaration.
In Alex' implementation, the mount adapter is also responsible for managing "top-level" registries that are often needed by programs, such as the Person registry.