It would be very useful to be able to trivially store the stream of data generated by a TV Kitchen appliance / passed to an appliance. This would be particularly useful for debugging implementations, debugging appliances, and writing tests for appliances.
There was some exploration of the idea of creating a recorder appliance to serve this purpose, but after thinking about it I believe that this should be a feature of the countertop. The countertop has much more context than an individual appliance would (appliances would only know about the contents of the payloads they receive; whereas the countertop knows things like kafka stream names, the overall topology, etc)
My initial thinking here is that enabling "recording" should take place as part of addAppliance. It's possible that we would want to provide the convenience of setting a countertop-wide / default recording configuration as well (e.g. configured on new Countertop()) but by starting at the individual appliance level it gives the developer access to more granular configuration options (e.g. they could specify different settings for different appliances / payload types / etc).
Part of this task will be making these decisions, however, and the above is not prescriptive. Ultimately the goal is to make it easy for a developer to generate a log containing the data that goes in / out of a given appliance. The format of that log is also to be determined (should it be valid JSON? just a log file? etc.)
Task
Description
It would be very useful to be able to trivially store the stream of data generated by a TV Kitchen appliance / passed to an appliance. This would be particularly useful for debugging implementations, debugging appliances, and writing tests for appliances.
There was some exploration of the idea of creating a recorder appliance to serve this purpose, but after thinking about it I believe that this should be a feature of the countertop. The countertop has much more context than an individual appliance would (appliances would only know about the contents of the payloads they receive; whereas the countertop knows things like kafka stream names, the overall topology, etc)
My initial thinking here is that enabling "recording" should take place as part of
addAppliance. It's possible that we would want to provide the convenience of setting a countertop-wide / default recording configuration as well (e.g. configured onnew Countertop()) but by starting at the individual appliance level it gives the developer access to more granular configuration options (e.g. they could specify different settings for different appliances / payload types / etc).Part of this task will be making these decisions, however, and the above is not prescriptive. Ultimately the goal is to make it easy for a developer to generate a log containing the data that goes in / out of a given appliance. The format of that log is also to be determined (should it be valid JSON? just a log file? etc.)
Related Issues