About Log4OM integration
Posted: 19 Jan 2020, 07:24
Some thoughts on system integration.
Some applications interface directly and "natively" with others. In this case the link is so close that if one of them changes, the other one doesn't work anymore. In other cases applications display a network port (sometimes selectable) and others use it.
Frankly speaking I've seen few applications that allow the same flexibility in terms of data reception and transmission on UDP like Log4OM 2, but this doesn't solve all the problems, because some applications, as said above, interface closely with specific functions of the other software.
This is the reason why, today, JTAlert cannot read the Log4OM 2 database: The Log4OM database has changed.
That said, the world of interconnections between systems is moving, for "non-critical" communications to UDP communication, compared to TCP communication, because it allows a much greater flexibility and an equally improved simplicity. This is why in the first version of Log4OM 2 we did not introduce TCP. And it is also possible that some applications used TCP to communicate with Log4OM because Log4OM v1 did not have many other reception methods.
We are considering introducing TCP, because it is possible that other colleagues who create applications may have the same desire to switch to UDP in their communications to Log4OM.
Surely communication in such an articulated world is almost an artistic matter. There is not only one way to do things, and I have seen with pleasure many colleagues invent ingenious solutions and think "out of the box". I share with you how I use JTDX, JTAlert and Log4OM v2 today, consider it another way.
First of all I have enabled in JTAlert the transmission of QSOs via UDP:
JTAlert Settings menu: Logging -> LAST QSO API -> Enable transmission of last QSO. I'm receiving it in Log4OM on port 2333 as ADIF INBOUND
Then i have enabled in JTAlert -> Applications -> WSJT-X / JTDX the option Rebroadcast WSJT-X UDP packets on port 2334. Log4OM is listening with JT_MESSAGE service on that port.
This will enable Log4OM to receive QSO and lookups while working a callsign (due to the message format, the callsign message is not arriving on the first stage of the QSO but doesn't belong to Log4OM)
by the way, with this system, nothing prevents you to have V1 running and aligned by JTAlert in the old way, providing statistics to JTAlert until they will release their integration routines. I'm actually working without JTAlert statistics, but it's a choice
Some applications interface directly and "natively" with others. In this case the link is so close that if one of them changes, the other one doesn't work anymore. In other cases applications display a network port (sometimes selectable) and others use it.
Frankly speaking I've seen few applications that allow the same flexibility in terms of data reception and transmission on UDP like Log4OM 2, but this doesn't solve all the problems, because some applications, as said above, interface closely with specific functions of the other software.
This is the reason why, today, JTAlert cannot read the Log4OM 2 database: The Log4OM database has changed.
That said, the world of interconnections between systems is moving, for "non-critical" communications to UDP communication, compared to TCP communication, because it allows a much greater flexibility and an equally improved simplicity. This is why in the first version of Log4OM 2 we did not introduce TCP. And it is also possible that some applications used TCP to communicate with Log4OM because Log4OM v1 did not have many other reception methods.
We are considering introducing TCP, because it is possible that other colleagues who create applications may have the same desire to switch to UDP in their communications to Log4OM.
Surely communication in such an articulated world is almost an artistic matter. There is not only one way to do things, and I have seen with pleasure many colleagues invent ingenious solutions and think "out of the box". I share with you how I use JTDX, JTAlert and Log4OM v2 today, consider it another way.
First of all I have enabled in JTAlert the transmission of QSOs via UDP:
JTAlert Settings menu: Logging -> LAST QSO API -> Enable transmission of last QSO. I'm receiving it in Log4OM on port 2333 as ADIF INBOUND
Then i have enabled in JTAlert -> Applications -> WSJT-X / JTDX the option Rebroadcast WSJT-X UDP packets on port 2334. Log4OM is listening with JT_MESSAGE service on that port.
This will enable Log4OM to receive QSO and lookups while working a callsign (due to the message format, the callsign message is not arriving on the first stage of the QSO but doesn't belong to Log4OM)
by the way, with this system, nothing prevents you to have V1 running and aligned by JTAlert in the old way, providing statistics to JTAlert until they will release their integration routines. I'm actually working without JTAlert statistics, but it's a choice