Open slifty opened 3 years ago
I slept on it!
I think insofar as the intent is debugging, this should be an option in the countertop API (e.g. when you register an appliance you can specify a debug recorder location for output or input payloads). The logic is that the countertop has more context -- e.g. kafka stream names, topoogy, etc, than a "recorder appliance" would and that context might be important for the debug use case.
I do still think a recorder appliance is something that should eventually be created -- and sure it could also be used for debug -- but I believe the use case would be different.
For example, I've been working on a TV Kitchen implementation which records SRT files and uploads them to dropbox. Some of this logic could (should) live in an appliance so that others can trivially record SRT files!
I'll keep this issue open for now even if the ultimate use case may end up shifting before implementation begins.
Task
Description
TV Kitchen appliances are hard to debug and improve because so often the issues that crop up come from wild and wacky real world data -- sometimes live data. This means that in order to reproduce it we would need to record the original video as it comes in.
Furthermore, when writing tests for a specific appliance we don't want to have to run a full pipeline, but rather we just want to re-play the specific payloads sent to the appliance. For example, when fixing this SRT bug #139 what I actually want is the
TEXT.ATOM
payloads that are causing the issue, not necessarily the original video.The bottom line is that the TV Kitchen ecosystem needs a convenient way to "record".
This use case could be met in a few ways:
I'm leaning to the second option (via an appliance) because it is more naturally flexible / one could add multiple "recorder" appliances to a given topology with various configurations.
The application approach (third option) could make a lot of sense eventually, but I feel the API isn't robust enough to do that kind of development yet.
The benefit of the first option (countertop feature) is that it would be a much more out-of-the-box "debug" feature of the system.