|
Thank you - I partly agree and would like to consider the comments from Sebastian and Kai to a "reduced" proposal:
My main point is to have a dedicated consumer cli integrated in Hono that is easily startable and does not need ANY own implementation efforts.
IMHO this is definitely lacking currently.
Initial functionality should be lean, but still helpful for device developers that want to see their telemetry data.
Grep is fine and can be very capable (especially if egrep is used) - but I have seen so many people fighting with their grep capabilities on more complex structures that I stick to my proposal of having simple dedicated filtering inside the implementation.
This includes :
- deviceId(s) for sure (like "$ cli-consumer --deviceId 'esp.*' --deviceId 'xdk4711.*' ....")
- applicationProperty keys (like "$cli-consumer --applicationPropertyKey 'myKey.*' --applicationPropertyKey 'myOtherKey'")
- applicationProperty values (like "$cli-consumer --applicationPropertyValue 'myValue.*' --applicationPropertyValue 'myOtherValue'")
Skipped from previous proposal:
- payloads : I would postpone after the discussion, since they might be more complex. I would expect binary (== hard to grep) payload as not being exotic.
- interactive mode: was more an idea and not a prio 1 feature
We would benefit from:
- having a dedicated cli for consumers (future improvals of features can be integrated)
- supporting (e)grep capable developers as well as people that are not _so_ good in complex grep patterns
- support environments without grep tools without additional effort
- pipe based egrep usages and/or even complex scripting evalutions of the output is by no means prevented and can be used by anyone who needs/wants to
AND:
this would not be hard to implement.
Thanks for opinions!
Karsten
|
