Procedural Context Extension

Date: 2025-03-28

In this note we review some concepts and steps required for extending procedural contexts in a plugin. For general plugin development guide, see Plugin.

Conceptual backgrounds:

• In the editor/runtime, when a procedural context graph is "executed" on its own, it will try to find a corresponding runner to handle the execution. The runner is library-implemented and can make use of ProceduralContextExecuter class which manages the node-level execution.
• The base procedural context must be platform agnostic (otherwise there is no point in developing it) - to isolate platform specific logic while registering only the platform-agnostic type as procedural context base type, we must use runner-interface pattern, where both the runner and the service provider interface instance can be specialized.

Creation steps:

1. Create a new context base off ProceduralContextBaseTypeApplication
2. If it doesn't require front-end specific logic, then we can implement a runner in the same package; Otherwise we need to follow the interface based pattern (see below).
3. Implement a plugin definition so Divooka runtime can recognize it.
4. Either register the plugin with runtime directly if it's PSL, otherwise publish it properly so people can download and consume it.

Design pattern for front-end specific logic:

1. For some examples, see existing code on RealTimeApplication and DesktopAssistant. Notice those two demonstrates two slightly different use cases.
2. Key idea is to dereference the events from the graph nodes and trigger actions when needed, while be aware of lifetime of involved objects throughout the process.