ObserverBatchEvent has to be called ObserverFileEvent, it's core application is file events, therefore it has path property. It could be "file was uploaded to S3/localFs" (for s3 and localFs responders). I don't think path is applicable for kinesis observer, which emits chunks of JSON. Therefore we need to introduce new kind of observer events, like ObserverCommandEvent.
It means that we can introduce another (root) level of trait hierarchy - ObserverEvent (without "Batch"), which can be superclass of ObserverBatchEvent and ObserverCommandEvent.
I think that @fingercos's Kinesis implementation should work with ObserverCommandEvent, not batch one. Notice, that it doesn't use path anywhere. It also doesn't make sense to use Option for streamContent, as we already have whole data (but file can be missing). So my point is that command and batch observer events are different.
This can be achieved with just few lines of code: ResponderEvent needs to be parametrized with ObserverEvent instead of ObserverBatchEvent and same for Responder.
ObserverBatchEventhas to be calledObserverFileEvent, it's core application is file events, therefore it haspathproperty. It could be "file was uploaded to S3/localFs" (for s3 and localFs responders). I don't thinkpathis applicable for kinesis observer, which emits chunks of JSON. Therefore we need to introduce new kind of observer events, likeObserverCommandEvent.ObserverEvent(without "Batch"), which can be superclass ofObserverBatchEventandObserverCommandEvent.ObserverCommandEvent, not batch one. Notice, that it doesn't usepathanywhere. It also doesn't make sense to useOptionforstreamContent, as we already have whole data (but file can be missing). So my point is that command and batch observer events are different.This can be achieved with just few lines of code:
ResponderEventneeds to be parametrized withObserverEventinstead ofObserverBatchEventand same forResponder./cc @alexanderdean @rzats