Broadcast Actor (AF with a touch of DQMH)

[jhoehner]

Broadcast Actor.zip

Hello All!

I'm looking for a little bit of feedback on an Actor I've put together. The zip file attached contains an Actor called "Broadcast Actor". I know the idea of a "broadcast" partially goes against the AF rules but bare with me. 

The reason I put this together is because the idea of an abstract message was driving me a little crazy. I probably haven't had it properly explained to me but in any case I decided to try and build something that accomplished a similar task as an Abstract Message while also maintaining the low/zero coupling abstract messages provide. I do know Interfaces are out and about in LabVIEW 2020 but this approach is for older code bases that we can't quite upgrade yet.

I loosely based this approach on DQMH which has an interesting architecture for messages going "up the tree" using broadcasts (user events), that parent modules register for when they start up. I figured something like this could also be implemented in an Actor. 

The attached broadcast actor has a message that returns its own populated "Event Cluster". Calling actors can call this message and are returned this "Event Cluster". The parent actor can then register for all of the events of the child actor in their Actor Core. I know reply messages are kind of discouraged in AF but this also felt like an okay way to use them. Once the child actor is up and running it can call it's own broadcasts which the parent can hear and do something intelligent with. My understanding of "low coupling" is limited, but I *think* this approach would prevent the parent actor from being loaded into memory if we are just trying to load the child actor. 

Maybe I'm way off or maybe this has been done before but it felt like a way to not have to use abstract messages (a barrier for some people to adopt AF), but also allow for low coupling between the actors themselves. 

Any and all feedback is welcome. What am I missing? 

-John Hoehner

[drjdpowell]

I think you'd get more chance of a response if you posted on the Actor Framework forum.  

I don't use AF or DQMH, nor have I looked at your code, but is it wise to try and combine different frameworks?  Frameworks are designed to support different design philosophies, which are not necessarily mix-and-match.  If DQMH makes sense to you while some of the AF stuff doesn't click, why not just use the DQMH?

[jhoehner]

Hey drjdpowell, 

Thank you for the feedback and yes good question... I think my intention is to try and combine good features from the two frameworks rather than try to mesh them together in their entirety. I think the idea of a broadcast from a generic child module up to a generic parent module through a user event is solid (DQMH has this feature by default). My team/customers familiarity with the actor framework is also good. A little more digging led me to a package on VIPM called the "Event Source Actor" which might already do what I'm trying to do (but better). I think I can take a stab at posting this in the AF forum as well but may have found my answer. 

Thanks again!

-John Hoehner