Hi all,
After some time being away from DX-ing, recently I've started over and I installed a new version of RUMLogNG. I'm greatly surprised on the evolution since that initial versions i helped to translate into spanish. Congrats for the nice work.
Coming back to the rationale for this message, due to a collateral reason, I've been working on a piece of software that connects to the cluster network and processes the spots, announces, WWV, WCY and other messages, like the skimmer information, and transports that data/details from the source, which is a telnet socket, into different backends, structured and unstructured. Examples of use can range from purely written the sports on the CLI with some order and format, generating JSON formats/files, writing on MySQL tables and/or publishing into MQTT topics. In short, this piece of software is something simple, quick and neat: a microservice.
The use case for this piece of software is rooted on the fact that cluster data, despite being telemetry-like, is erratic in the format and can be cumbersome to handle. I know that this statement can sound relatively bad, but, the truly fact is that despite the cluster network today remains fully operational, not without challenges, things can be simpler, more standardised, and we can leverage much more the extensive set of tools IT can provide nowadays. In 2019, theres no good reason (and believe me, I'm saying this with a good rationale behind) to keep on reinventing the wheel with legacy systems/technologies. Moreover, maintaining the cluster network as it is today in the coming future is a risk, as technologies behind the cluster network are obsolete. But, that's another story.
:: The request / proposal ::
That being said, the short-term request or proposal is to provide RUMLogNG with a capability to get cluster data from a MQTT connection, in exactly the same way today information is gathered from a telnet socket or from a ever-growing log file on a local dx cluster installation, like many well-known dx portals do, or running legacy apps on workstations acting as local clusters, just to name a few.
In regard to the format inside the MQTT publications, i think the most effective would be the usage of free text but, that wouldn't make MQTT too much different from today's clusters. There are better combinations. The value added on having a simple JSON over MQTT is the perfect combination to me. I can demonstrate how effective this can be with live data. Even better, I can craft a public Docker container to demonstrate this fact.
Then, finally, I'd like to know if you all find this functionality interesting. In addition to the expressed use case we can have many more like, potentially, improvements in the software used for contests, team dx-peditions or even a revamp on the cluster software itself.
Let me know your thoughts.
Best regards / 73s
EA1HET
Jonathan