01-25-2023 04:03 AM
Another way that I've solved this is to have the Stream and Image Acquisitioner actors just broadcast images indiscriminately (ether by interface Msg or loosely/zero-coupled Msg) and leave it up to the receiving actors to decide whether the want to process the newly acquired image or not.
One advantage of doing it that way is that the requesting actor isn't coupled and doesn't need to know anything about the Stream (or any other) actor - it simply receives information that it can either process or discard. This makes it easier to test actor subtrees in isolation.
The disadvantages are that this takes more memory (though in my experience it hasn't made a difference) and that time synchronization for specific actors can be trickier. YMMV...
Wouldn't my Image Acquisitioning actor be coupled to the receiving actors? That might be usefull in some cases, but I suspect I am more likely to use Image Acquisitioner in another project than the receiving actors.
01-31-2023 03:46 PM
The Acquisitioning actor wouldn't be coupled to the receiving actor(s) if you used interfaces. It could probably also be done by Abstract Msgs.
If you didn't/can't use interfaces, but had a common ancestor actor then it'd be loosely coupled. (i.e. The ancestor actor has a message that the Acquisitioning actor uses and the receiving actors implement.)
But the main point of either is to not use the receiving actors' concrete messages.