11-20-2022 09:10 PM
I could not find a definite answer to this in the forum, so a couple of questions to AF enthusiasts from a non-AF developer:
Thanks,
Dmitry
11-21-2022 10:01 AM
How often? Never within an application. I consider pub/sub to be useful (even critical) across networks, but at this point I consider it to be an anti-pattern within an application.
11-21-2022 10:20 AM - edited 11-21-2022 10:20 AM
Since I would only consider pub/sub for network connection, what API I used would depend upon interoperability requirements with non-LabVIEW systems.
If my app is a subscriber, I would probably have one subVI called in my root actor that registers my needs with the server. Then I’d have (either A) a simple helper loop in root actor or B) a nested actor) that listens for messages from server and turns them into messages for my root actor.
If my app is a publisher, then I may have one or multiple nested actors publishing out value changes to the server in the places within my app where those values change. I’m unlikely* to have just one actor whose job it is to publish state unless there’s some protocol requirement that many value changes be packaged together. If that req exists, messages will percolate up to the actor that can see the coherent state, which will then publish them out.
11-21-2022 10:25 AM
11-21-2022 10:36 AM
Just a side comment but the AF does actually use a type of Pub/Sub, in it's various "zero-coupling" techniques. But this is a very local application of the principle, applying only to Caller-Callee interactions. Dmitry's ArT stuff is a global Message-Broker Pub/Sub which can connect anyone to anyone.
11-21-2022 11:07 AM - edited 11-21-2022 11:08 AM
@AristosQueue(NI) wrote:
How often? Never within an application. I consider pub/sub to be useful (even critical) across networks, but at this point I consider it to be an anti-pattern within an application.
Do you consider the scenario of a LabVIEW host application communicating with a cRIO attached to the host PC as 'within an application' or 'across networks'?
During a not-so-recent project, I did wish for the capability to have topic-based pub/sub capability, so that:
Using my limited knowledge, I ended up having my root actor be the 'broker'. This definitely has opportunity for design improvement. Suggestions would be very welcome for me to consider for a future project.
11-21-2022 11:18 AM
None of the AF zero-coupling connection techniques allow for arbitrary connections. A protocol handshake is not a pub/sub pattern. Claiming it as a degenerate pub/sub is highly misleading in my opinion.
11-21-2022 11:31 AM
> Do you consider the scenario of a
> LabVIEW host application
> communicating with a cRIO attached
> to the host PC as 'within an
> application' or 'across networks'?
Host to cRIO is network, but being network doesn’t mean sub/pub necessarily. I only mean there are network scenarios where pub/sub is critical, not that it is always the solution. 🙂 Your use case sounds like a good one for that.
11-21-2022 11:52 AM
@AristosQueue(NI) wrote:
None of the AF zero-coupling connection techniques allow for arbitrary connections. Claiming it as a degenerate pub/sub is highly misleading in my opinion.
It's a minor bugbear of mine that perfectly good english words get highjacked to only refer to specific technical things, including aspects unrelated to the original english meanings. I know you and Dmitry are talking about using a message broker, but an outsider might not. And it complicates talking about non-broker-based publication and subscription designs.
11-21-2022 12:23 PM
@drjdpowell non-broker-based publication and subscription designs.
I don’t think I’ve ever heard the term outside of such systems. As far as I’m concerned, pub/sub is message brokering, by definition. A service publishes its information and clients subscribe for updates. What else is there?