Extension registries
Registries
Section titled “Registries”Prefer the public Extension SDK import path: drtoller.framework.ext (load_plugins, register_*).
| What you extend | API | Cookbook |
|---|---|---|
| Dataset sink/source (incl. new DB) | register_write_backend / register_read_backend |
backend, DB |
| Step pattern/mode | register_pattern_runner / register_mode_runner |
execution mode |
| Parallel transport | register_parallel_backend |
Parallelism |
| Embed / cluster method | register_embed_method / register_cluster_method |
algorithm |
| metric_defs.method | register_method |
metric method |
| evaluation method | register_evaluation_method |
algorithm + evaluation |
Principle
Section titled “Principle”New capability = registration, not editing a central if-forest. Extensibility is a first-class design goal of the open Framework: contributors add algorithms, metrics, evaluation methods, storage and parallelism backends, execution modes, and integrations through registries and plugins — then humans and external AI can discover those primitives in the capability catalog and compose them into DRTML.
- Pattern/mode builtins:
runtime/pattern_runners.ensure_builtin_runners - Parallel transports:
partition_loop/parallel/backend_registry - Plugins: entry points group
drtoller.pluginsviaext/discover.load_plugins(called fromrun_from_manifest) - Machine-readable contracts:
drtoller.framework.capability(build_catalog/inspect) — see Capability catalog
processing.dispatch re-exports pattern/mode register helpers for compatibility; canonical tables live under runtime/.
When registering algorithms, pass optional info= (AlgorithmMethodInfo) so catalog metadata stays next to the registration.
Dynamic import
Section titled “Dynamic import”execution.entry and legacy runners: runtime.import_utils.import_symbol
(do not keep import_utils under processing/).
Dispatch diagrams: How a run executes.