Design new StatusPort

[mossmaurice]

Brief feature description

After this discussion the conclusion was a StatusPort or BroadcastPorts is beneficial for #415 and for the introspection topics, in order to prevent any user to take() the data and not release() which could lead to a out-of-memory error.

Detailed information

• Design document for StatusPort
• Implement StatusPort Moved to Implement StatusPort #1096
• Send ServiceRegistry via StatusPorts (see service registry as a built-in topic #415) Moved to Implement StatusPort #1096
• Replace InterfacePorts with StatusPorts Moved to Implement StatusPort #1096

References

• Comes from service registry as a built-in topic #415

[elfenpiff]

@mossmaurice maybe I missed something but the purpose of the interface port is to forward capro messages for instance to gateway ports.
And the purpose of the StatePort is to deliver some kind of state. How should we be able to replace the InterfacePort with a StatusPort?

And shouldn't it be called StatePort instead of StatusPort?

[mossmaurice]

@elfenpiff

maybe I missed something but the purpose of the interface port is to forward capro messages for instance to gateway ports.

That's correct. More broadly speaking InterfacePorts are used to relay discovery information to gateways. After the StatusPorts are available we should consolidate them with both the InterfacePorts and the introspection 2.0 by sending the ServiceRegistry via a StatusPort. For more information also see the design document. Very likely it will be fleshed out from this issue and implemented in a separate one.

And the purpose of the StatePort is to deliver some kind of state. How should we be able to replace the InterfacePort with a StatusPort?
And shouldn't it be called StatePort instead of StatusPort?

I think that's a misunderstanding. I'm talking about these StatusPorts or BroadcastPorts.

[mossmaurice]

Not needed anymore. Closing.