What level of complexity per each Actor is best / most practical?

[RMThebert]

What is the smallest chunk of code worth isolating with AF for reuse?

I have been looking Actor Framework Demo and Angry Eagles Demo to understand how to best apply the Actor Framework to my application.  The idea of having every tiny piece of code (even set one Boolean) become its own packed project library seems like a lot more work than it is worth.  The demo is not concerned with what is under it, and keeps it simple to show only the AF, I understand that.  Both demos have hung the computer (Win7 LabVIEW2011SP1) by leaving VIs without visible panels running in the background, so I am not convinced that AF has a guaranteed stop that really works.

..

Practical use question:

Given that I have two unrelated applications (Main and Chmbr) already built using the JKI state machine structure, I want to be able to launch and communicate with Chmbr from Main.  I do not want to write AF code to set each Boolean or DBL value.  I do want to begin using the AF concept so that Chmbr will be generic enough to be shared.  My time is very limited to add the AF functionality.  What AF functionality can I create for this?

..

Here's what I want to do with AF:

1) Launch Chmbr from Main

2) Chambr does its own thing and when it requires actions to be taken by Main it will send a message to initiate that action.

2.5) The messages will be at least once per second, better if they are events.

3) Main only needs to listen for the messages and be able to stop the Chmbr.

4) Chmbr needs to set what hardware it controls into a predefined state when it is stopped.

5) I will build other versions of Chmbr that can stand alone and can use the AF to connect in place of Chmbr

..

Here's my previous method which seems robust and is easy to drill down through by clicking on the diagrams which all easily fit one screen: 

1) put the Chmbr VI on the diagram of Main (before the JKI starts in parallel with the subVIs)

2) Main has another subVI which creates and registers events for Main, Chmbr and several other parallel tasks

3) Main has an event error handler for each parallel subVI  (each parallel subVI is in charge of its own piece of hardware or other function)

4) Main has an event for each parallel subVI output event that it cares about (only a few)

5) Main has a handle on the subVI events that are used for commands.

6) Each parallel subVI has the ability to run stand alone for development and troubleshooting.

7) I can add peer to peer among subVIs but have no need.

My previous method is tightly coupled, so the AF I am hoping to loosen the coupling a bit for easier reuse.

[Daklu · Accepted solution]

What is the smallest chunk of code worth isolating with AF for reuse?

The completely correct but absolutely worthless answer is, one where the time saved by having the reusable code is greater than the cost of creating and maintaining it. If you're looking for specifics, a single actor (and its associated messages) is generally the smallest chunk of code worth generalizing, but I can imagine scenarios where reusing individual messages would make sense.

The idea of having every tiny piece of code (even set one Boolean) become its own packed project library seems like a lot more work than it is worth.

I fully agree, but I'm not sure why you mentioned PPLs. PPLs are completely unrelated to the AF.

I am not convinced that AF has a guaranteed stop that really works.

No framework can guarantee that without also drastically limiting what it allows you to do. Using powerful features such as dynamically launching parallel vis puts more responsibility on the developer to make sure it is done correctly. (FWIW, I haven't had any problems with those two apps.)

I do want to begin using the AF concept so that Chmbr will be generic enough to be shared. My time is very limited to add the AF functionality. What AF functionality can I create for this?

With all due respect it sounds like you have a solution looking for a problem. AF is not a silver bullet for turning specific code into a generic reusable component. Furthermore, retrofitting the AF into an existing application is decidedly non-trivial. Given that your time is very limited and you appear to be unfamiliar with the AF (and perhaps LVOOP as well,) I humbly suggest the AF is not the best solution for you at this time. AF will help you implement a good design. It will not fix an inadequate design for you.

The key to loose coupling is having a well defined interface and managing your dependencies. You already have an event-based messaging system implemented in your applications. In my experience, event based messaging often leads to highly coupled systems due to rampant typedef use. (It is not always the case, but it often is.) If your public Chmbr api is defined well enough to generalize and you've controlled your dependencies appropriately, I recommend looking into traditional techniques to launch the specific Chmbr versions dynamically. It will be a cleaner fit and the learning curve will be much easier to handle in the time frame you have.

(If you insist on using the AF, I imagine it would be possible to write adapter actors around Chmbr and Main that translate between AF messages and user events. I probably wouldn't bother trying it except for an academic exercise.)