On 4/22/2021 2:06 PM, Rui Oliveira wrote:
In my particular case (and it's not unique to me at all), I have a
series of devices that I'd like to support, which have completely
different and unrelated controls. This might be my "stuck mindset"
talking, but I've seen this problem solved as I explained: "bring your
own controller", and yes, a widgets object and a "logic" object with
pointers to each other.
It's not a stuck mindset it's an x86 mindset.
"Everything needs to be linked into one program."
Fugetaboudit
Everybody should have to take COBOL and CICS when getting there
programming degree. Much like the Kevin Bacon game, everything in IT
eventually boils down to a CICS transaction.
User launches CICS application. CICS engine throws screen up on terminal
while actual application runs in a batch queue. User tippy-tap-types
away at terminal. Eventually they hit one of the limited function keys
like <ALT><PA1> or they hit the funky little enter key. Either a partial
or full screen of data gets sent as a message on the CICS message queue
for the batch job. Eventually batch job wakes up, reads message, does
something with it. Maybe that something sends a different screen or
additional data back to the terminal, maybe not.
The first thing you need to do is decide what type of message you are
going to use?
1) Serialized CoA (Common Object Array) most common in embedded world.
2) JSON
3) XML
4) Roll Your Own
After that you need to write yourself, buy, or find a publish subscribe
message queue. You also need to decide if the queue depth for each
message type will be one or N. It may sound horrible, but a depth of one
is very common.
This message queue runs as its own little daemon/process on the system.
As each piece of your application comes up it looks for this message
queue via some known name or other method. They connect to it and
subscribe to the messages they want to receive. Most will make you
announce the messages you intend to broadcast.
Each device runs as its own process/daemon. Your UI runs as its own
process/daemon. It also connects to the message queue. There is no
business logic in the UI. There is none of the "glue" layer stuff others
have been chatting about. If it needs data in certain columns and sorted
order it sends a CoA message asking a service for it. *If* a service is
subscribed it will assemble the data as requested and publish a
different CoA message.
You **always** publish without wait. Absolutely nothing waits for a
response. Maybe something has already subscribed to your message, maybe
it hasn't. You issue the request and cease to care at that point. If you
are working in a SAFETY environment you publish the message and launch a
timer that will trigger some kind of error log/indicator if a response
is not marked as received within a certain window. You **never**
actually wait for the response.
Devices come, devices go. When a device connects it needs to publish
"Hey I'm Here!" It may connect and publish before the UI is alive. When
the UI connects the first message it publishes is "Sound Off!" telling
all of the subscribing devices to say "Hey I'm here!"
Nobody cares if anybody actually listens.
This back of the matchbook architecture works for large scale business
systems spread across multiple business class operating systems and
architectures all the way down to tiny medical devices.
No matter how much people hate green screens, we will never get away
from CICS. When you try to get away from it you create tragedy.
If it helps, think about it this way:
A happy successful robust application has a whole lot of processes that
simply don't care. Like a musician playing a song in a room all by
themselves, they don't need an audience. If they have an audience,
great! If not they are still going to play.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
