Actor Framework Discussions
Calle-to-Caller message
Thank you all for your responses !
@CaseyM
That's exactly, I didn't have the right term but I'm looking to create a plugin architecture with the actor framework.
The problem with interfaces is that you have to go to the class properties to modify it. I don't want that, I want that after designing the fundamental actors, we don't need to modify them to add a new interface. If my Callee inherits my Caller's interface, then is there still a question of dependency?
➡️ I can try to make things simple enough to avoid plugins bringing new functions. I can keep a common API.
➡️ I made a sequence for you to detail what I expect from the behavior of my actors. Hope this helps you understand the problem better.
Maybe I misunderstand how interfaces work and that it is possible to inherit them dynamically.
@zsmorison
Thank you for your very clear response. I have to evaluate the 2 solutions you propose to decide which one to apply.
I would prefer less control in my framework actor but maintaining rigor in the tree hierarchy. Perhaps the solution would be to send the command messages from my device through my sequence by addressing it directly. The fundamental actors would only do message addressing. It may be better than giving the enqueuer of a device directly to my sequence.
@Dhakkan
The two actor packs could be independent if I know the functions (init, stop, send msg). I like the way the formatted channel works. I also use this principle to control other instruments. The question would then be how to implement my 3-4 messages described above so that my addons (plugins) inherit them.
@syuiopwdfghj wrote:
I will keep you informed of the progress of the project but the AF to PPL thread seems to answer the problems.
I don't necessarily want to dissuade anyone from using AF and PPLs, but anyone who does needs to go in with their eye wide open. Switching to PPLs has a lot of benefits when it comes to enabling plugin architectures, but there's a LOT you need to consider as well. Here's a short list:
- Dependency management - No getting around this - it needs to be buttoned up and on point. This can be a large task by itself depending on the size of the project.
- Converting to PPLs tends to have a creeping effect - You'll find that it's not just Actor.lvclass that needs to be a PPL but everything in the inheritance tree and lots of other classes that might get used.
- There are many bugs (I've experienced more times that'd I'd like) that come with PPLs - XNodes, malleable VIs, even property nodes can all cause problems (especially on an RT system).
TL;DR - switching to PPLs isn't an easy task and has its own set of dangers and considerations and the switch shouldn't be taken lightly.
If you do go that route and find that you need help with the things I've mentioned, my company has a lot of experience with this and we'd be happy to talk about ways we can help.
@syuiopwdfghj wrote:
Maybe I misunderstand how interfaces work and that it is possible to inherit them dynamically.
@zsmorison
Thank you for your very clear response. I have to evaluate the 2 solutions you propose to decide which one to apply.
I would prefer less control in my framework actor but maintaining rigor in the tree hierarchy. Perhaps the solution would be to send the command messages from my device through my sequence by addressing it directly. The fundamental actors would only do message addressing. It may be better than giving the enqueuer of a device directly to my sequence.
@Dhakkan
The two actor packs could be independent if I know the functions (init, stop, send msg). I like the way the formatted channel works. I also use this principle to control other instruments. The question would then be how to implement my 3-4 messages described above so that my addons (plugins) inherit them.
Thanks for the details - it's helpful.
You are correct that interfaces cannot be inherited dynamically, but if you need the main application to be able to handle new information from plugins without modification to the fundamental actors, the interface to handle that information needs to already exist. I don't really see a way around that so I don't quite understand what you expect the Sequence Manager to do with the "NotifyVoltage" Msg if the interface isn't already in place.
Another issue is passing routing a Msg from one plugin to another when the fundamental app has no knowledge of the plugins a priori. We designed this utility to handle that exact situation:
https://www.vipm.io/package/zyah_solutions_lib_zyah_af_msg_forwarding/
There's more to unpack there but maybe looking at it can give you some ideas.
Generally a conflict like that appears when you have code that links to both the PPL and non-PPL version of Actor.class. i.e. You have code in your project that is used to build PPLs and also code that depends on those built PPLs.
If it wasn't obvious from that last part, you'll end up needing several different projects (generally one per lvlib) to build the PPLs and then another project that contains the code that's actually linked to the PPLs. Things like LabVIEW Solution Builder can help, but I recommend learning the more manual way first.
If you've done all that and are still seeing issues, to go any further I'd probably want to see the actual code. If you're interested in our company's services and want to pursue specifics, shoot me a PM and we can talk more.
