Fixing Replay Feeder

[erikbosch]

I do not know how much effort we want to put into this component, but it was definitely broken.

What I did:

• Created a log file with KUKSA.val Server (now included as example)
• Making sure that it can be used to inject data back to KUKSA.val Server.

If we want to support this component in the long run we should better create some tests, but that is not the intention of this PR

[erikbosch]

I changed the example/default config so that it works if you have kuksa.val.feeders and kuksa.val cloned in parallel.

[SebastianSchildt]

I am not sure we want to keep this component in the long run. For playing -sans the "re" we have https://github.com/eclipse/kuksa.val.feeders/tree/main/csv_provider now, and I wonder it won't be better to have component that could create a compatible CSV log, basically "KUKSA recorder"m using Py API only, to effectively get the same behavior

I think @eriksven, you looked into it, but not 100% sure.Where there fundamental hurdles except "only 24 hours in a day"?

This tool originally was really a val-server only thing, depending on a "hacked" version of an internal class, which means for one, currently there is no way to create such logs for databroker, and second not sure this "deeply integrated" way was the best architecture pattern to begin with...

Other opinions?

[SebastianSchildt]

Oops just noticed #105 Should look at it :)

I sort of feel, if that works, this whole thing can be removed.

[erikbosch]

The other tools ( csv_provider and #105) (AFAIK) only supports KUKSA.val Databroker, while this one only supports KUKSA.val Server.

My view is:

• In the long run we should not have different tools for Databroker/Server, i.e. the Replay Feeder shall in the long run be removed and replaced by the others.
• But then it comes to the question on how we look at the future of KUKSA.val server. If we think that we will deprecate KUKSA.val Server "soon" it is not worth the effort to add websocket-functionality to the other tools, but then maybe keep this tool alive until KUKSA.val Server is obsolete
• If we decide to use the recorder/provider concept for KUKSA.val Server as well (should be doable), do we then still want to keep the logging concept in KUKSA.val Server (i.e. the format consumed by this tool)? This question is however only relevant if we intend to keep KUKSA.val Server for a reasonably long time.

For the near future we could do like this:

1. Merge this PR, it does not hurt regardless of how we will continue
2. Create an issue to handle the decision if we should keep this feeder or do the effort of making the others support websocket as well.

[lukasmittag]

I agree, will not hurt anyone, if we merge this. We should remove once we deprecate KUKSA.val server.