Request and wait for reply or Roundtrip?

[1984]

Hi,

I've been in a situation many times when I created a Request and wait for reply event and then later on it turned out that it would be great if this request could also broadcast out its results. Currently there is no easy conversion between a Request and a Roundtrip event, so I'm wondering if it makes sense to create all requests as roundtrip?

Would it cause any problems (structural or performance besides a bit of an overhead)?

(on the same note I dont get the point of making a "request" instead of "request and wait for reply". The latter can be easily used as a Request just by connecting false to its wait for reply terminal. Sure it will have a reply payload and another VI or two, but thats probabyl not an issue at all in 99.999% of the cases)

Thx!

[Olivier-JOURDAN]

Hello,

I know developers who do as you say (always creating "request & wait for reply" even if they don't need a reply). I'm personally on the team who likes the code to be as readable and kind of auto-explanatory. If not, you can push the reasoning only to create cloneable modules instead of singletons. I don't feel this is a good thing to understand the architecture of your app.

I'm not sure it will cause problems for small to medium size apps.

For large apps (more than 30+ modules), I'd fear some slower code editing and longer build time. 

[joerg.hampel]

---

@Olivier-JOURDAN wrote:

Hello,

I know developers who do as you say (always creating "request & wait for reply" even if they don't need a reply). I'm personally on the team who likes the code to be as readable and kind of auto-explanatory. If not, you can push the reasoning only to create cloneable modules instead of singletons. I don't feel this is a good thing to understand the architecture of your app.

I'm not sure it will cause problems for small to medium size apps.

For large apps (more than 30+ modules), I'd fear some slower code editing and longer build time. 

---

I have said the exact same thing so often in the past that I was sure I had posted this reply, and I was really confused for a second why you show as the author, Olivier, not me 😂😂😂

I completely agree: If my design calls for an asynchronous message, I will create a request without reply to convey my intent. If my design does not require a module to be instantiated multiple times, I will create a singleton module. These decisions make the code much more readable.

That being said, some people choose to go with request and wait for reply and cloneables as their default and also create great software.

[ChrisFarmerWIS]

1) Always create a roundtrip rather than a request and wait for reply?

 - Hopefully a future version of DQMH scripting will allow you to automatically change from a request and wait for reply into a roundtrip.

2) Why bother with a Request any more?

 - Historically the Request and Wait For Reply (DQMH 4 and earlier I think?), did not have the Wait for reply option, so there was definitely a difference back then.  I very rarely use a Request any more.

[1984]

---

If not, you can push the reasoning only to create cloneable modules instead of singletons. 

---

Yeah, I have asked that question couple months ago 🙂 I think though that there is a lot bigger difference between using only cloneables than using only roundtrip.

The key problem is that there is no easy conversion between the Requests and Roundtrips, so if you didnt fully design your system upfront perfectly then you may end up creating custom broadcasts which is equally if not even more confusing than just having broadcasts only without using the broadcast function.

Not sure what should I do, but thanks all for the responses.

I have submitted a feature request the last week about this topic, but its possible that it was requested before. (https://forums.ni.com/t5/DQMH-Consortium-Toolkits-Feature/Convert-Requests-and-wait-for-reply-to-Rou...)

[Olivier-JOURDAN]

---

@1984  a écrit :

---

If not, you can push the reasoning only to create cloneable modules instead of singletons. 

---

Yeah, I have asked that question couple months ago 🙂 I think though that there is a lot bigger difference between using only cloneables than using only roundtrip.

---

Sorry, I missed (or forgot) that.

---

@1984  a écrit :

---

The key problem is that there is no easy conversion between the Requests and Roundtrips, so if you didnt fully design your system upfront perfectly then you may end up creating custom broadcasts which is equally if not even more confusing than just having broadcasts only without using the broadcast function.

---

I can't remember wanting to do that modification often during the last four years I've been using DQMH daily. And creating the equal broadcast manually (things I'm sometimes doing) works for me. I'm not confused about it, but I completely understand it could confuse some of us.  

---

@1984  a écrit :

I have submitted a feature request the last week about this topic, but its possible that it was requested before. (https://forums.ni.com/t5/DQMH-Consortium-Toolkits-Feature/Convert-Requests-and-wait-for-reply-to-Rou...)

---

Thank you for taking the time to create the request. We will examine this and let you know if we can/want to implement it in the future DQMH release.

[breiter56]

It looks like the consortium has weighed in. Here's some rookie perspective. I don't really know what I'm doing yet, and my projects evolve quickly. I like the versatility/scalability of the Roundtrip. So far, the only downside has been a little less room to work in the MHL due to the additional case structure.