Improvements to the plugin system with examples

[ivan-cukic]

No description provided.

[RalphSteinhagen]

👍 Looks good!

Some more structural comments on the dynamic ports and hire functions. The main things that should IMO be addressed in this PR:

• finding a good global naming and renaming the various uses of tag_t::map_type, fair::graph::node_construction_param, ... definitions to that.
• The choice of having ports that are statically and/or dynamically defined should be dependent on the base class but IMO, always use the node<T> CTRP-base class (N.B. to be renamed -> block<T> to be consistent with existing GR3 naming conventions)
• the hier_node (I guess soon named hier_block or perhaps sub-graph ) concept is good and one of the two possible/needed implementations ... we need to look for a nice API where users can declare the sub-graph in the sense of 'grouping' and or sub-domain with its own scheduler.

@ivan-cukic what do you think?

[RalphSteinhagen]

This should be handled with node parameters and the initialisation been done in

  uint32_t n_input_ports = 3;
public:
    void init(const tag_t::map_type &old_setting, const tag_t::map_type &new_setting) noexcept { /*...*/ }

[ivan-cukic]

For later, added a comment - it needs dynamic ports to be supported by fg::node

[RalphSteinhagen]

why not use node::set_name(..)

[ivan-cukic]

For later, added a comment - it needs dynamic ports to be supported by fg::node

[RalphSteinhagen]

if you could add a 'TODO' comment, we should aim to merge this logic with the existing node::work() implementation.

@wirew0rm also setup an issue for this: #81

[RalphSteinhagen]

... notably because this does not include tag handling and we should expose only the 'work()' function to the users on rare and very special cases.

[RalphSteinhagen]

is this needed? the node_model has this definition as well...

[ivan-cukic]

raw exists in order for graph to be able to find nodes (a node doesn't know it is wrapped in something, when it wants to communicate with graph, the graph needs to be able to 'see through' the wrappers.

[RalphSteinhagen]

derive it from node?

[RalphSteinhagen]

node-model can still wrap the strict type.

[RalphSteinhagen]

LGTM 👍 !

The things that need to be tackled in later PR are documented.