Module initialization from Start Module and other ideas...

[Mads]

First off, thanks for making and publishing the DQMH, it is a very cool product.

I'm in the process of utilizing the DQMH for a first time, and based on my current understanding of it (might not be correct, perhaps all I need is some guidance), I have come up with some feature requests:

1. A way for the creator of a module to provide parameters for the Message Handler Initialize case. The Start Module.vi currently only sets the Module Admin input of the module. The creation of this VI could be scripted to include whatever parameters the initialization would need (the same way we do for requests now). I guess the current way to do this is to create a separate initialization event and issue that after creation, but this would then not run until after the initialization has been done... (I posted this earlier in a separate thread but I cannot find it anywhere...perhaps it is awaiting approval?).

2. A way to name modules/module clones during creation and then address them by name instead of by Module ID (Currently the creator(s) of modules woudl need to administrate a linked list here outside the DQMH framework...or we have to  request every module for their identity (now set using a request, in the future perhaps set with featire 1 above) and/or broadcast a message with a  target name in it).

3. Requests with a To/From/ReplyTo header: This one is a bit less general, but anyway: In one of my current use cases, modules might a) use a *lot* of time before the Message Handling Loop is able to process a request (it is doing time consuming work)...and b) the sender of the request might not necessarily be the one needing the reply. It would be cool to be able to issue a request to a module saying "take you time" - whenever you have finished handling this message (very long or even infinite timeout), send the reply to this given queue. (I would use queue here instead of notifier.) Here it would also be nice to just specify the target (queue) by name. That way the code issuing the request only needs to know the name (address) of the intended target (queue), not generate and supply a queue reference. 

Regards,

Mads

[FabiolaDelaCueva]

Mads wrote:

First off, thanks for making and publishing the DQMH, it is a very cool product.

Hi Mads,

Thanks for the feedback, we are pleased to hear that you are liking the DQMH and if I may be too bold to ask, please don't hesitate to rate the toolkit at the Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286#ratingsAndReviews

Mads wrote:

I'm in the process of utilizing the DQMH for a first time, and based on my current understanding of it (might not be correct, perhaps all I need is some guidance), I have come up with some feature requests:

1. A way for the creator of a module to provide parameters for the Message Handler Initialize case. The Start Module.vi currently only sets the Module Admin input of the module. The creation of this VI could be scripted to include whatever parameters the initialization would need (the same way we do for requests now). I guess the current way to do this is to create a separate initialization event and issue that after creation, but this would then not run until after the initialization has been done... (I posted this earlier in a separate thread but I cannot find it anywhere...perhaps it is awaiting approval?).

I think you are referring to the discussion here: https://decibel.ni.com/content/message/129035#129035

We have created a case in our internal DQMH project to at least include the guidance bookmarks that Darren suggested on that thread. Adding the scripting DQMH magic to create the arguments may have to wait a little longer. Like I mentioned in the other thread, even in the cases where we were convinced we needed to send the argument at start module, we ended up removing them in favor of a configuration file or sending a post module initialization request. If we start hearing from more people needing this feature or if we start using it more on our own development, it will be included in future DQMH versions.

Mads wrote:

2. A way to name modules/module clones during creation and then address them by name instead of by Module ID (Currently the creator(s) of modules woudl need to administrate a linked list here outside the DQMH framework...or we have to  request every module for their identity (now set using a request, in the future perhaps set with featire 1 above) and/or broadcast a message with a  target name in it).

We realize that the clone management provided is the bare minimum. We figured out early on that the projects that needed the clone modules, required different clone management schemes. Instead of trying to provide a full solution that would meet all needs, we left it at the clone ID level as a template starting point. The clone management is its own library within the Clone module, so as long as you keep the same API for all the VIs used there, you could replace the inner workings of the library to handle the conversion from name to clone ID and from clone ID to name.

That said, I will create a case in our internal project, if we hear of more people requesting this feature, we might include it in a future DQMH version and/or in a DQMH Project Template.

Mads wrote:

3. Requests with a To/From/ReplyTo header: This one is a bit less general, but anyway: In one of my current use cases, modules might a) use a *lot* of time before the Message Handling Loop is able to process a request (it is doing time consuming work)...and b) the sender of the request might not necessarily be the one needing the reply. It would be cool to be able to issue a request to a module saying "take you time" - whenever you have finished handling this message (very long or even infinite timeout), send the reply to this given queue. (I would use queue here instead of notifier.) Here it would also be nice to just specify the target (queue) by name. That way the code issuing the request only needs to know the name (address) of the intended target (queue), not generate and supply a queue reference. 

This seems like a very specific feature and I am trying to think of a case where we might have done something similar and I cannot think of anything. If it comes to me later, I will add a comment to this case.

In the mean time, the way to address what you want to do is to create a Request and modify the Request Argument--cluster control to have a queue reference and the queue name. When the MHL receives the request, it would have as its argument the queue type (given by the queue reference) and the queue name to where to deliver the reply to. The queue reference would already have the queue type and would not need to be provided by the caller. The input to the Request.vi would be only the Queue Name, the queue reference part of the argument could be sent as a constant.

Now, you will need to figure out where/when the queue would be created, read and destroyed. 

Hope that makes sense.

Thanks again for your interest on the DQMH.

Regards,

Fab

[Mads]

FabiolaDelaCueva wrote:

Mads wrote:

2. A way to name modules/module clones during creation and then address them by name instead of by Module ID (Currently the creator(s) of modules woudl need to administrate a linked list here outside the DQMH framework...or we have to  request every module for their identity (now set using a request, in the future perhaps set with featire 1 above) and/or broadcast a message with a  target name in it).

We realize that the clone management provided is the bare minimum. We figured out early on that the projects that needed the clone modules, required different clone management schemes. Instead of trying to provide a full solution that would meet all needs, we left it at the clone ID level as a template starting point. The clone management is its own library within the Clone module, so as long as you keep the same API for all the VIs used there, you could replace the inner workings of the library to handle the conversion from name to clone ID and from clone ID to name.

The benefit of having namable clones instead of an auto-generated module ID is that we can embed at least *some* information in the name, and thus we may also know how to refer to a module if we have knowledge about how the names are generated (which we have, as we would generate them). This is also why adding a name to the initialization process works as a general solution for initialization - the name can carry enough information to enable the modules to figure out how to do the initialization (in a project specific way) regardless of whether that would for example involve reading a config file. If a config file is the suitable initialization in the given scenario then by having a name the modules can have the rest of the process in their logic to actually locate that file. If the initialization should retrieve parameters from elsewhere the same goes; with a name you can have associated logic; with an auto-generated module ID you have nothing. (and as naming is established as a known method of referral in many primitives, like queues etc, it is the closest thing to a standard minimum).

Mads wrote:

3. Requests with a To/From/ReplyTo header: This one is a bit less general, but anyway: In one of my current use cases, modules might a) use a *lot* of time before the Message Handling Loop is able to process a request (it is doing time consuming work)...and b) the sender of the request might not necessarily be the one needing the reply. It would be cool to be able to issue a request to a module saying "take you time" - whenever you have finished handling this message (very long or even infinite timeout), send the reply to this given queue. (I would use queue here instead of notifier.) Here it would also be nice to just specify the target (queue) by name. That way the code issuing the request only needs to know the name (address) of the intended target (queue), not generate and supply a queue reference.

This seems like a very specific feature and I am trying to think of a case where we might have done something similar and I cannot think of anything. If it comes to me later, I will add a comment to this case.

In the mean time, the way to address what you want to do is to create a Request and modify the Request Argument--cluster control to have a queue reference and the queue name. When the MHL receives the request, it would have as its argument the queue type (given by the queue reference) and the queue name to where to deliver the reply to. The queue reference would already have the queue type and would not need to be provided by the caller. The input to the Request.vi would be only the Queue Name, the queue reference part of the argument could be sent as a constant.

Now, you will need to figure out where/when the queue would be created, read and destroyed.

To attack the subject a bit different; when a reply may come late, and the target for that reply is not the same as the one who requested the data, we can today choose to define a broadcast event instead to issue the reply. The code waiting to process the reply can then register for broadcast events and look for the event(s) it is interested in and/or check within the event data if it is indeed intended for it.

The use of broadcast event has the upside that we do not have notifier and timeout, and the receiver can be someone other than the requester. The downside (in some cases) is that the event is broadcasted.A mechanism where a module can use user events to reply, but use a "private" user event instead, would give the benefits of the user event, without the broadcast bit.  (I can live with the lack of "privacy" for my current application though, so in the previously described scenario I use broadcast events to deliver the result, and have a recipient included in the data. That means that my receiver is able to pick up the reply and figure out that it is intended for it. Others can listen in...but I'll at least have some use for that for debugging/system monitoring.)

[FabiolaDelaCueva]

Hi Mads,

We have added to DQMH 3.0 the option of creating DQMH modules from your own DQMH templates. This should help you modify the "My Cloneable" template to use names instead of numbers and from then on use that template instead of ours.

If you are interested in becoming a Beta tester, please sign up for our DQMH newsletter (if you have not done so already). We will be sending the Beta testers link in the next couple of days.

Regards,

Fab