Skip to content

feat(pj_plugins): expose parser capability tags on the runtime catalog#83

Open
pabloinigoblasco wants to merge 1 commit intomainfrom
feat/parser-capability-tags
Open

feat(pj_plugins): expose parser capability tags on the runtime catalog#83
pabloinigoblasco wants to merge 1 commit intomainfrom
feat/parser-capability-tags

Conversation

@pabloinigoblasco
Copy link
Copy Markdown
Collaborator

Summary

Propagate the parser capability tags already parsed from the plugin manifest JSON onto the host-visible RuntimeMessageParserPlugin so host code can discover them before instantiating the parser.

What changes

  • RuntimeMessageParserPlugin (in pj_plugins/include/pj_plugins/host/plugin_runtime_catalog.hpp) gains a std::vector<std::string> capabilities field, populated by PluginRuntimeCatalog::loadAndRegisterMessageParser from PluginDescriptor::capabilities.
  • New example DSO mock_media_parser_plugin (pj_plugins/examples/mock_media_parser.cpp) declares "capabilities":["object"] in its embedded manifest and exercises the dual-emit path — scalar seq field plus opaque blob via objectWriteHost()->pushOwned().

Why

Hosts need to discover a parser's capability tags before instantiating the parser, so they can selectively register optional services such as pj.parser_object_write.v1. The "object" tag is the first real consumer of this channel.

The example DSO doubles as a template for plugin authors that need to emit binary payloads (images, compressed frames, serialized messages) alongside scalar fields, and as a real plugin that exercises the manifest → catalog → host propagation path end-to-end.

How to test

  • Build with PJ_BUILD_TESTS=ON; confirm mock_media_parser_plugin.so is produced.
  • Run plugin_parser_object_write_test (in pj_datastore/tests) — exercises the SDK path that composes scalar + object write hosts from one parse() call.
  • Sanity check: existing parsers without the "object" capability surface an empty capabilities vector, which leaves their host-side wiring unchanged.

Propagate the parser capability tags already parsed from the plugin
manifest JSON onto the host-visible RuntimeMessageParserPlugin so host
code can discover them before instantiating the parser.

Changes:
- RuntimeMessageParserPlugin gains std::vector<std::string> capabilities,
  populated by PluginRuntimeCatalog::loadAndRegisterMessageParser from
  PluginDescriptor::capabilities.
- New example DSO mock_media_parser declares
  '"capabilities":["object"]' in its embedded manifest and exercises
  the dual-emit path (scalar seq field + opaque blob via
  objectWriteHost()->pushOwned()).

Hosts that need to selectively register optional services (e.g.
pj.parser_object_write.v1) before calling parser->bind() can now read
the tag list directly from the catalog. The 'object' tag is the first
real consumer of this channel; the example DSO doubles as a template
for plugin authors that need to emit binary payloads alongside scalar
fields.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant