Great presentation Luis!
Just a few comments after a quick dig through of the DQMH code:
The difference between the singleton vs clone-able modules at a high level I think is a slight performance/memory gain. The clone-able modules have more extensive initialization code than the singleton and also differentiate between events meant for them versus other clones as seen here. The singleton modules are also not re-entrant.
Modules themselves do confirm back that they have started as a part of the framework however the one caveat is that this is done as a part of the module Main.vi which means a user could conceivable remove this functionality if they did not know what it was for.
Finally, commenting on the SMO vs Delacor question and specifically why SMO uses objects. I believe this has to do with commonizing the framework APIs. You can start/stop any SMO with the same API calls, the use of opbject oriented programming makes this very easy. DQMH appears to create unique APIs for each module.
Thanks for sharing DQMH with your user group. You mentioned in an email to me that there were two questions that you would like for me to expand on, so here are my comments.
1) Difference between Singleton and Cloneable in terms of memory, efficiency and why DQMH has Singleton if it is possible to create a Cloneable with the Singleton behavior.
You can read more about the difference between Singleton and Cloneable in the DQMH Documentation.
The existence of the Singleton module is two-fold:
Blackburnite also made some good observations on his post above regarding the differences. Blackburnite said "Modules themselves do confirm back that they have started as a part of the framework however the one caveat is that this is done as a part of the module Main.vi which means a user could conceivable remove this functionality if they did not know what it was for."
There are several things in the Main.vi that could cause the module to not behave as expected, however, we expect that LabVIEW programmers will be using the DQMH API Tester to launch and test their code. The scripting tools even encourage the programmer to keep their DQMH API Tester up to date. A DQMH out of the box does three things very well: "Starts when we tell it to start and reports back immediately, reports errors to DQMH API Tester (or stops in error if running as a stand-alone), stops graciously and immediately". If the DQMH module stops doing any of those three things, then it is something the programmer just did. Running the DQMH API Tester after each new event has been created or new features have been implemented will ensure that the programmer would know immediately that they removed something they shouldn't have removed.
2. Why DQMH is not LVOOP based?
We decided to limit the LVOOP to be done inside the DQMH module. Our main objective was to make DQMH accessible to teams with different levels of proficiency. This includes teams where some programmers are not familiar and do not want to become familiar with LVOOP. This allows the programmers who do want to use LVOOP and are comfortable with LVOOP to use it inside the module itself and provide a public API that does not contain any LVOOP at all.
For other ways to combine LVOOP and DQMH, check out the HAL post at the Delacor blog. Also, I gave a presentation at NI Week with some other tips and tricks for DQMH projects and there is a section (tip 5) where I describe other ways LVOOP can be used with DQMH.
DQMH also has a feature where LabVIEW programmers can create their own DQMH Module Templates and still take advantage of the DQMH scripting tools, the shipping example of a module template replaces the local data with an object.
It was never our intention to have everyone use DQMH. We understand that every team is unique and have their own needs. If the entire team is comfortable with LVOOP and work most of their time in LabVIEW, then Actor Framework might be a better option for that team. If a team has their own framework and it works for them but they would like to add some automation for the repetitive tasks as we have done, we would be more than happy to help them get there.
If you want to discuss DQMH more, please visit the DQMH forum.