In Streamix side ports play a not well defined role. They provide the possibility to broadcast signals which is a good idea. But it is very annoying to use them as every side-port has to be explicitly forwarded through a wrapper (not through nets, which is good).
A new view of using side-ports could be to see them as a bus. A bus would be declared in a scope, e.g
bus my_awesome_bus
Which would allow to connect each net to this bus, provided the net as access to the scope the bus is defined in.
Connecting to a bus would happen through side-ports. I.e side-ports would no longer represent a collection (like up and down) but be a separate thing used to connect to a bus.
Separating side-ports in such a manner from normal streams would allow the RTS to use a completely different approach to implement data distribution over a bus:
It could still be done as usual with routing nodes and decoupling (with the draw-back of potentially large amounts of routing-nodes)
It could be done with a new type of node which handles all messages specific to the bus (and thus, reduce the number of routing nodes)
In Streamix side ports play a not well defined role. They provide the possibility to broadcast signals which is a good idea. But it is very annoying to use them as every side-port has to be explicitly forwarded through a wrapper (not through nets, which is good).
A new view of using side-ports could be to see them as a
bus
. A bus would be declared in a scope, e.gWhich would allow to connect each net to this bus, provided the net as access to the scope the bus is defined in. Connecting to a bus would happen through side-ports. I.e side-ports would no longer represent a collection (like up and down) but be a separate thing used to connect to a bus.
Separating side-ports in such a manner from normal streams would allow the RTS to use a completely different approach to implement data distribution over a bus: