I've been using your actor/messenger libraries for a couple of years now. I have an ecosystem of actors that register themselves with a registrar actor. Any actor can look up any other through the registrar. This function is limited to a single machine.
I want expand this service to lookup across machines using tcp/ip messengers. Additionally I want to communicate to asynchronous python processes that would look very much like your actors. They would have publish/subscribe (observer registry) services, and they would send and receive messages like your LV actors.
Do you have any examples of python communicating to your actors/messengers via tcp/ip? I don't want to reinvent anything.
Many thanks for your library!
I'm afraid I've had no projects requiring interoperability, yet, but my plan is to make use of JSON as a common format. It would require a modified TCP Connection/Client Actors (those that actually handle the TCP link).
So a message going out over TCP might look like:
"Label":"Request Channel Data",
"Reply To Address":"kjsdbkjcskdjcbjdsckjdsdcj"
Then the reply coming back over TCP would be like:
Note the the Reply Address can be anything, including just a flattened LabVIEW Object, as the receiving Python side doesn't actually need to do anything with it other than pass it back along with the reply. This means that quite a lot of Messenger Library functionality will work without any effort, as it is built into the Address stuff. For example, that Address above might be "Relabel 'Save Channel Config' and send to QueueMessenger 0x2342441 and EventMessenger 0x8767675"; the Python actor wouldn't need to understand any of that.
To get a working Server-side Python "actor", you would need to implement the Message and Reply as above, plus Registration Messages and Notifications. Notifications would look just like the Reply above, while a Registration Message might be:
"Address to Register":"vbsfgbfsgnfsgnfgnfgsnfgsnfgsgfsbmy"
Actually, I remember did do a limited test of talking to a C++ app of another developer. Sadly that project got cancelled. But we were using JSON format (just of Request-Reply) similar to above. An advantage of JSON is it is a well-established standard for interoperability.
Unfortunately, implementing this is more work that I can justify without having an actual paying project to use it on. I'll have a look to see how much work it would be to make "JSON communication" an option in the TCP stuff. That would make it easier for you to just build the Python side to interface.