Hi Luiz, Johan, On Sun, 2019-03-24 at 11:00 +0200, Luiz Augusto von Dentz wrote: > Hi Johan, Brian, > > On Sat, Mar 23, 2019 at 12:08 PM Johan Hedberg < > johan.hedberg@xxxxxxxxx> wrote: > > Hi Brian > > On 22 Mar 2019, at 16.00, Gix, Brian <brian.gix@xxxxxxxxx> wrote: > > On 22 Mar 2019, at 5.49, Inga Stotland <inga.stotland@xxxxxxxxx> > wrote: > +# 5 - on/off model client menu > +# 6 - send raw message > +# 7 - exit > > Please don’t use numeric identifiers for commands in interactive > tools. Use intuitive, human readable strings like we do in the other > interactive tools in the tree. Numbers might be convenient for > computers, but they’re not particularly human friendly :) > > We do plan on making better tools, but this is mostly intended as a > tester script to quickly allow us to test stuff, particularly the d- > bus APIs, and demonstrate the way the methods are called from python. > > Understood, however what I proposed > > - Doesn’t take really any extra effort > - Is friendlier to the user > - Is friendlier to the reader of the code (no need to do number > lookups to understand the purpose of a branch) > - Is consistent with the rest of the code base > > … so I don’t understand why you wouldn’t want that, even if it’s a > quick test tool :) > > +1 > > > I suppose the long-term idea is to provide the same kind of > interactive command-line interface as meshctl has provided for > provisioner and configuration client role? In fact, would it make > sense to keep using meshctl for that and hide the detail whether > stuff is going via meshd or not? > > There is actually a lot in common to meshctl so I wonder why not > extend it to work with meshd instead, or we do intend to abandon it? > I > thought its code would be assimilated by meshd and then reworked... meshctl is a pure GATT-based provisioner tool. The plan is to re-work it once there is an integrated support for GATT-based an PB-Adv mesh. > Anyway our python scripts are just small samples currently and Id say > we should keep it like that and not have full blow clients since > there > are better tools for it, for instance there exists python bindings > for > BlueZ which might be extended to work with meshd: > > https://pypi.org/project/bluezero/ > > This particular python script is not going to grow into a full-blown client. It's not a tool, it's an example. Maybe it's a misnomer to call it a test and have it the test directory. Will it be acceptable if it lives under mesh/samples directory and, thus, does not create inconsistency with the rest of the tree? > > Johan >
