Re: [PATCH BlueZ] test: Enable test-mesh to send raw vendor commands

From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Johan Hedberg <johan.hedberg@gmail.com>
Cc: "Gix, Brian" <brian.gix@intel.com>,
	"Stotland, Inga" <inga.stotland@intel.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ] test: Enable test-mesh to send raw vendor commands
Date: Sun, 24 Mar 2019 11:00:50 +0200	[thread overview]
Message-ID: <CABBYNZLAau4paWF9yoLXzUzmJnVawDiZWaVZUnwZfGqhRsQnMw@mail.gmail.com> (raw)
In-Reply-To: <E232C390-8571-40A5-9E72-2499E9973959@gmail.com>

Hi Johan, Brian,

On Sat, Mar 23, 2019 at 12:08 PM Johan Hedberg <johan.hedberg@gmail.com> wrote:
>
> Hi Brian
>
> On 22 Mar 2019, at 16.00, Gix, Brian <brian.gix@intel.com> wrote:
> >>> On 22 Mar 2019, at 5.49, Inga Stotland <inga.stotland@intel.com> 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...
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/

> Johan

-- 
Luiz Augusto von Dentz