feat: add DataProvider and OperationProvider plugin interfaces#355
Draft
feat: add DataProvider and OperationProvider plugin interfaces#355
Conversation
New provider interfaces for plugins that serve standard SOVD data and operation resources on plugin-created entities. Per-entity routing (unlike singleton Log/Script/Update providers) allows multiple plugins to each handle their own entity sets.
PluginLoader queries get_data_provider() and get_operation_provider() C exports from plugin .so files, following the same pattern as existing get_log_provider/get_script_provider queries.
Entity ownership map (entity_id -> plugin_name) enables per-entity routing to DataProvider/OperationProvider. Populated from IntrospectionProvider results.
Plugin entities now appear in the entity cache regardless of discovery mode (runtime_only, manifest_only, hybrid). In hybrid mode, plugins participate in the merge pipeline as before. In other modes, entities are injected during the regular cache refresh cycle. All plugin entities get source='plugin'. Entity ownership is tracked in PluginManager for per-entity provider routing.
EntityInfo now has is_plugin and plugin_name fields, populated during entity lookup from PluginManager's ownership map. Enables handlers to check entity ownership without querying PluginManager directly.
Data handlers (list, read, write) check EntityInfo.is_plugin and delegate to the owning plugin's DataProvider instead of querying ROS 2 topics via DataAccessManager.
Operation handlers (list, execute) check EntityInfo.is_plugin and delegate to the owning plugin's OperationProvider instead of looking up ROS 2 services/actions via OperationManager.
When a plugin entity has DataProvider or OperationProvider registered, the entity detail response automatically includes 'data' and 'operations' in the capabilities array.
Tests verify entity ownership tracking in PluginManager: registration, lookup, multi-plugin coexistence, provider resolution via add_plugin (in-process dynamic_cast), and nullptr returns for unknown entities and plugins without providers.
bburda
force-pushed
the
feature/plugin-entity-framework
branch
from
daf6a84 to
81db09c
Compare
… ops The move constructor and move assignment operator were missing data_provider and operation_provider fields, causing them to be silently lost during plugin loading. This made get_data_provider_for_entity() always return nullptr even though dlsym successfully discovered the providers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Summary
Add per-entity provider routing for gateway plugins, enabling plugins to serve standard SOVD data and operation endpoints on entities they create via IntrospectionProvider.
DataProviderandOperationProviderinterfaces (per-entity routing, unlike singleton Log/Script/Update providers)get_data_provider,get_operation_provider)source = "plugin"Issue
Type
Testing
Checklist