Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Hono CLI proposal part 1 - consumer

On Wed, 2017-03-22 at 09:45 +0000, Frank Karsten (INST/ECS4) wrote:
> 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'")
I would suggest to try to also allow for shorthand versions of these params, e.g.
--id instead of --deviceId or --key instead of --aplicationPropertyKey etc

> 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
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit

Back to the top