search

illuminated-g / lv-msg-simple

Simple messaging layer that works with lv-stream based communication layers
MIT License
1 stars 0 forks source link

Question: Why Callbacks instead of a Case Structure in a Message Handling Loop #5

Open drjdpowell opened 1 year ago

drjdpowell commented 1 year ago

I would have thought that a Queued Message Handler (with a case structure selected by the Message ID) would be a lot more familiar to people. You, instead require Callback VIs for each message. A valid choice, but I think it would be a lot harder for many people to adopt.

negentropicdev commented 1 year ago

I don't want to lock into a single design pattern or architecture. Plus, I come from a text programming background where things like callbacks, delegates, lambdas, and all sorts of other fun mechanisms run rampant. Yes, a VI wrapper is needed, but with the context you can pass in, you can give the callback a message queue if that's what you want. Or an event reference. Or update a DVR. I use this with all sorts of app architectures and module patterns so I aim for flexibility in allowing any higher layer design patterns.

It's certainly not the most prevalent pattern in LV but why should that be a limiting factor? Teaching teachable people is easy :)

negentropicdev commented 1 year ago

Another reason with this design, many modules can be supplied with the connection to communicate over and can subscribe to messages on a single connection. Which message handling loop would get the message? One big loop would be needed at the application layer to cover all the reusable libraries? If a library is written to use this implementation, messages can be multiplexed without caring about the rest of the application. All an app needs to do is provide the module with the connections/endpoints to use.

negentropicdev commented 1 year ago

It would certainly be possible to implement a different messaging layer that directly ties into a QMH pattern. Or a QMH layer on top of the messaging layer.

drjdpowell commented 1 year ago

Suggestion then: 1) Have the ability to register a single Callback for all messages. This allows an easy way to adapt your library into an existing massage-based architecture. 2) Have an example that uses this to pass messages to a message-handling loop. Maybe choose a lightweight framework like the JKI State Machine and show how you can pass messages into it via a User Event. This example would serve as a template for the User to adapt their own existing message-passing methods.

drjdpowell commented 1 year ago

Actually, maybe get in touch with the DQMH people. That is a widely used framework without a well-developed TCP solution, which uses individually-type messages (User Events) that might match well with your Callbacks.

negentropicdev commented 1 year ago
  1. I'm hesitant on this because that's not really what this is meant for. If 1. is really desired I would say a different messaging layer could be implemented which I'm more than happy to do. I'd prefer to err on the side of "safety" in that modules only handle external messages that they're expecting, which is normal for nearly any messaging API I've seen whether any host of pubsub systems, SystemLink messages, etc. It also creates a list of clearly defined messages that are expected from external software. It's not really that difficult to setup a string array with a list of expected messages to iterate over and register for and encourages purposeful API design.
  2. I've created https://github.com/illuminated-g/lv-msg-simple-examples/issues/1 to have an example of that created with the QMH project template and look at creating examples for other QMH patterned frameworks.

I'm looking into integrating with DQMH but they already appear to have a Generic Networking Module available though of course that's meant strictly for DQMH module - DQMH module messaging. With my APIs it would be easier to expose web UIs and messaging with other non-DQMH systems so I'm going to get in touch with a few of the consortium people and plan a path forward for this.

joerghampel commented 1 year ago

HSE's Generic Networking (GenNet) modules were designed around the use case of using a module's API (its request VIs) on one computer but actually executing the functions on another computer. Although GenNet can be used to just communicate between applications, that was not the first use case in mind.

While handy for our own projects, the GenNet modules in their current form are not trivial to use for others, as there is no scripting to a) convert an existing module to a networked one (basically overwriting the DQMH Message Queue class) and b) implement requests and replies in a GenNet compatible way.

It's worth pursuing this idea here and discussing this some more.

negentropicdev commented 1 year ago

@joerghampel I've started https://github.com/orgs/illuminated-g/discussions/1 to continue the DQMH integration discussion. Probably over this next weekend I'll take a first pass at a web UI for the thermal chamber example and we can have something to start pulling apart.