Calle-to-Caller message

[syuiopwdfghj]

Good morning,

In the development of my project, I am faced with a problem which is the following :

I created an actor A which launches an actor B. Actor B is developed by the user of my project (addon system). I'm looking for a way to communicate messages from actor B (nested) to actor A (caller).

I identified 2 solutions :

1. Use a self-addressed message which would allow me to not have any coupling between the 2 actors but this prevents me from transmitting messages with data.
2. Use an interface. This works very well but actor A must have the interface of actor B which poses a problem for the addon system.

Any idea of what could be done ?

Thanks

[Oli_Wachno]

How would solution 1.) help with what you want to achieve?

[syuiopwdfghj]

This solution allows me to create a self-addressed message with the message to be transmitted (Start Acq for example) as well as the recipient's enqueuer. The problem is that I don't go through a send message (Send Start Acq Msg), so I can't store any data in my message.

[CaseyM]

---

@syuiopwdfghj wrote:

The problem is that I don't go through a send message (Send Start Acq Msg), so I can't store any data in my message.

---

You don't need to use the Send method to put data into a message. A message is a class just like any other - just use accessors to populate the data. 

But what exactly are you trying to do? From your example it sounds like you are trying to send a message from B to A just to send a message back to B. Why?

[Dhakkan]

---

@syuiopwdfghj wrote:

This works very well but actor A must have the interface of actor B which poses a problem for the addon system.

Can you elaborate what problem this scenario poses?

Assuming you are trying to follow the Actor Tree approach for communication, it is indeed logical for Actor A to have the Interface of Actor B to send the latter (request) messages.

If, on the other hand, you are referring to (event) messages that Actor B has to send to 'its caller', you could still use Interfaces (plural intended). Actor B invokes such messages with the only knowledge that its caller has implemented the said Interfaces. Note that these Interfaces don't necessarily belong to Actor B. It's just that Actor B has a usage-dependency on said Interfaces.

Just to be explicit, each LabVIEW Interface class can be maintained in its own library, and you can use the Actor Framework Message Maker to create reusable messages for all the public methods of the Interface.

EDIT: Fixed typo.

[syuiopwdfghj]

Thank you for your answers. I will try to explain my project better.

I have a core folder where I develop my fundamental actors (UI, logging system, ...) and I have an addons folder where I develop actors that I can do without (analyzer, power, transmitter...).

My project does not depend on these actors and above all, the end user of my project must be able to create their own actors.

I obviously provide documentation to describe the communication between my fundamental actors and my addons.

All my fundamental actors communicate through clear messages sent to the enqueuers (whether in Caller-to-Callee or the reverse). They can be dependent because they are part of the fundamental system of the project.

On the other hand, addon actors must be completely independent of my core system.

I can cast them as actors because they all come out of the Actor class so with their path, I cast them as follows :

I am now looking for a simple method to communicate to them (Caller-to-Callee) and from them (Callee-to-Caller)

• Caller-to-Callee can be done by fetching messages that the class has and casting them in the same way with the Message class of the actor framework.

• Callee-to-Caller, I have 2 options :

1. Use an interface. Devices Manager inherits the interface from the addon but this poses a problem because a blue actor (fundamental) depends on an orange actor (addon). It's not possible.
2. Use a self-addressed message. This is possible but if I want to put data there, I have to add a Setter to my message class (doable but not automated with the actor framework).

Spoiler

I want my Caller and my Callee independent so abstract is not a solution (since the Caller message inherits the Callee message).

Can be used abstract messages which have the interface behavior with the data accessibility of classic messages, while being automated by the actor framework.

However, I understand that abstract messages are used less and less.

I hope to enlighten you a little more.

[CaseyM]

OK, so it sounds like you're developing a plug-in architecture. I second what Dhakkan said about interfaces - there's no reason using interfaces should necessarily couple you to your plug-ins (add-ons). Your fundamental actors would depend on the orange actor interfaces but not the actors themselves. But your interfaces, in a scenario like this, should probably be abstract enough that this should be fine.

Is the problem that your new plug-ins add new functionality (via new APIs) to the existing, fundamental application? I could see that being an issue, but if your new actors call existing interface APIs already present in the system, you should be good to go.

Perhaps you could give a concrete example (maybe using the "Measure Voltage" message?) and describe where you expect the Msg to be generated from and where it needs to be sent to?

[CaseyM]

---

@syuiopwdfghj wrote:

• Callee-to-Caller, I have 2 options :

1. Use an interface. Devices Manager inherits the interface from the addon but this poses a problem because a blue actor (fundamental) depends on an orange actor (addon). It's not possible.

If you're communicating from the nested actor (Callee) to its caller, you probably want to be using the caller's interface if it's a request Msg to perform some action.

[zsmorison]

Why do your framework actors (Devices Manager) need to send device specific messages to the plugin actors (devices)? This makes it feel like you are trying to assign a lot of a lot of control to your framework actors, when less control might be better. I would approach this kind of framework design in one of two ways depending on the level of control that the framework actors need to have.

Low framework control: You have different types of addon actors in your diagram. Could you let the addon actors (sequence actor <-> device actor) communicate with each other instead of having your devices manager send these addon specific messages? (This might require message forwarding or intentional violation of the actor tree communication hierarchy depending on your tree structure). This kind of design would increase the coupling between the addon actors, and shifts responsibility for understanding how to send/receive the device specific messages to the code developed by your end user. This is presumably ok if both types of addon actors are being developed by your end users, and it's probably the approach I would favor because I wouldn't have to anticipate everything that the end users could try to do. Think of the plugins for a text editor like VS Code. The editors usually give the plugin developer a way to add control elements that will be accessible by the user (i.e. add plugin options to menus or display custom views). But beyond very basic functions (like loading the plugin), the editor itself isn't controlling features of the plugin. That level of control is encapsulated within the plugin.

High framework control: If your device manager needs to have a high level of control of the addon devices, then (as other users have pointed out) you should have a well defined interface or set of abstract messages. Think of something like the specs designed by the IVI Foundation for instrument control. The interface does not have to be part of your framework, but it does need to be available to your framework which means you have to put in the work up front to define it and then your users will have to adhere to it.

[Dhakkan]

---

@syuiopwdfghj wrote:

I obviously provide documentation to describe the communication between my fundamental actors and my addons.

...

On the other hand, addon actors must be completely independent of my core system.

---

The two statements are paradoxical to me. The two sets of actors - fundamentals and addons - cannot be completely independent; as they need to follow the communication specification your documentation describes.

That's the whole point of Interfaces - to codify the messaging contract between Classes.

If you would rather not (or cannot) use the Interface feature, you could implement the callee-to-caller event messages via string data type. You could use JSON, or virtually any formatted string approach that complies with your communication document specification. The consequence here is that one or more of your fundamental actors needs to know how to parse the string for further action.

Alternately, as zsmorison implies in 'Low framework control', your communication documentation could be limited to specifying what a Sequence-To-Execute addon actor needs to implement to communicate with the Sequence Manager.