Publish jet1090 decoded messages to Redis pubsub

[emctoo]

Opt in when a --redis-url is provided.

By default the topic is jet1090, you can change that with --redis-topic foo, for example.

Setup a local Redis by docker run -d --rm --name redis -p 6379:6379 -p 8001:8001 redis/redis-stack:latest. More on https://hub.docker.com/r/redis/redis-stack.

[xoolive]

Thanks @emctoo! The code looks good to me.

I am just wondering:

• should it be here in default mode or as a "redis" feature? (if so, let's do it)
• does this behaviour make websocket channels #18 irrelevant?

[emctoo]

should it be here in default mode or as a "redis" feature? (if so, let's do it)

Yes. Will work on it.

does this behaviour make #18 irrelevant?

WebSocket functionality remains relevant. But its implementation approach warrants careful consideration.

The current pull request introduces a substantial amount of WebSocket-related code. If merged, it would significantly increase the maintenance burden for rs1090. I propose developing this as a separate crate or at least an independent GitHub repository, which we can then integrate as needed. This approach offers greater flexibility and maintainability in the long term.

While the newly merged Redis publishing feature theoretically allows us to publish data to a public Redis service topic for widespread use, maintaining a publicly accessible Redis service poses numerous challenges, particularly in terms of security. In this context, distributing and sharing jet1090 data through a WebSocket service emerges as a more practical and secure alternative.

Additionally, I'm considering creating a general WebSocket server within the new crate that would subscribe to data from a Redis topic and publish it via WebSocket. This could incorporate additional features and evolve independently. Redis would serve as a bridge, eliminating the need for extra work in the main repository.

In essence, this approach would result in a more streamlined WebSocket integration for rs1090, while also offering the option to use WebSocket functionality as a standalone service if preferred.

I suggest we discuss this topic further in our next meeting. Hopefully I can demo ideas here.