Attached is a sketch of a publish-subscribe solution inspired by the design of the native queue functions. Open the project and launch the Simple Demo.vi to get an idea of the concept (or create a few instances of the example templates and run those). As you know there are *lots* of messaging solutions out there that also support many to many communication, many of which are much more advanced. They are often based on user events, and LVOOP. I have still been missing a solution that is as easy and intuitive to use as queues though. I also wanted to overcome a few other issues with user events:
- I do not like to always have to have an event case for each subscriber. - I want each subscriber to be able to preview or flush its incoming data stream...(not fully implemented yet, but logically simple to do) - and I want to be able to keep a channel open for as long as anyone is interested in using it, not die when the process thathappened to create it goes idle(which is what happens with queues and user events...). I am publishing this to get some feedback on the concept (as it is now it has lots of missing logic and the design is not thought that much through). Do you find it useful or just silly? Are there other solutions out there that are just as simple? PS - The original attachment was LV2014, I have now added a 2012 version as well. MultiQ - a sketch of a many to many (pub-sub) messaging solution.zip
I have been trying to come up with a way to make my program more efficient. I am trying to use less nested case structures, and to avoid calling sub VIs multiple times. I looked at some of the design patterns, and there was not a sole design pattern available that did what I wanted, so I have tried to combine 3 patterns into one.
My application has a user interface controlling a camera, and each function is context sensitive. For example, if the camera is already acquiring images, the "change video mode" function needs to unconfigure acquisition before adjusting the settings. If the camera is not doing anything, the unconfigure step isn't necessary.
My previous attempt used nested case structures to test the condition of all these criteria, and take the required action, so there were cases for every combination of states. I wanted the code to be more minimalist, and call functions (sub VIs) in a state machine in a different order, skipping certain cases, depending on the context. I wanted to combine the low CPU usage of the event structure with the queued message handler example, to take an array of states and process them one at a time.
My first attempt is attached. I used notifiers because I don't want steps to be queued if the user presses multiple commands before completion. I want to only process the first command received after the current notifier changes are made. I couldn't think of a way to change between using the array from the notifier and using the modified array (minus the deleted element) in a shift register, so I used the send notification inside the slave loop to send the modified array of states. I want to know if there is a better, more efficient way of doing this, and whether there are any problems here.