@PrimaryKey wrote:
Thanks. I find that my approach is the easiest possible approach to achieve sub/pub using zero coupling. Thee is nothing less you can do without removing features.
Is the reason for the wrapper messages to allow for zero coupling in both directions, so the subscriber doesn't have to depend on a member of the publisher's library?
I'm currently experimenting with a different approach:
1. Create an abstract class as normal. Add an enqueuer to the class data.
2. Create a write accessor for the enqueuer. Modify the Send VI to use this enqueuer to send the message.
3. Pull this class out of the publisher's library.
4. Write the publisher as normal, but note that the publisher no longer needs or has access to the subscriber's enqueuer.
5. Create children of the message class that target subscriber's methods, as normal. Note that the scripting tools work as expected with this different abstract parent.
6. At run time, register the subscriber with the publisher. Subscriber writes its enqueuer to the child message, and hands off the message to the publisher.
Publisher does not have subscriber's enqueuer, and you have a couple of methods that you can use to set this up so that subscriber doesn't have publisher's enqueuer either. Publisher and subscriber both depend on an abstract message class, but not on each other (equivalent to your current arrangement). No custom work is required on the subscriber's child messages, and it would be a simple task to roll code so script the abstract parent as well. If I were still at NI, I would pitch creating a pub/sub abstract message that included the custom work in 1 and 2, and options to let the user pick the abstract message type (standard zero coupling or pub/sub) and whether the abstract message was attached to an actor library or not.
I may post something after I get clear of the CLA Summit next week.
By the way, as I type this, I am remembering that CaseyLamers1 proposed another zero coupling pub/sub scheme not too long ago that has some features in common with your solution. I'll point him this way, and maybe after the CLA Summit, we can start a longer dialog.
I like the idea of using the variant database for managing the subscriber lookup, and I could see fracturing that out as a simple LabVIEW class. I don't think you have to flatten the enqueuers to strings, though. Variant to Data works on classes.
