From: Steve Brown <sbrown@cortland.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
Steve Brown <sbrown@cortland.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 2/3] mesh: meshctl: Add commands
Date: Mon, 11 Dec 2017 09:14:44 -0700 [thread overview]
Message-ID: <1513008884.4454.34.camel@ewol.com> (raw)
In-Reply-To: <CABBYNZ+MUHG-DTuwbGWG6Nk6wigKok3gkJJRfAc3NiN1xametA@mail.gmail.com>
Hi Luiz,
On Mon, 2017-12-11 at 13:49 -0200, Luiz Augusto von Dentz wrote:
> Hi Steve,
>
> On Mon, Dec 11, 2017 at 1:40 PM, Steve Brown <sbrown@cortland.com>
> wrote:
> > Hi Luiz,
> >
> > On Mon, 2017-12-11 at 13:12 -0200, Luiz Augusto von Dentz wrote:
> > > Hi Steve,
> > >
> > > On Mon, Dec 11, 2017 at 12:58 PM, <sbrown@cortland.com> wrote:
> > > > From: Steve Brown <sbrown@cortland.com>
> > > >
> > > > Get/Set Proxy
> > > > Get/Set Ident
> > > > Get/Set Relay
> > > > Set Heartbeat
> > > > Get Publication
> > > > Get/Set Subscription
> > >
> > > Ive split these into individual patches for command and then add
> > > in
> > > the description what the expected output, etc. Btw I think it
> > > would
> > > be
> > > better to switch from get-set style to cmd [value], so if there
> > > is no
> > > arguments then it just read the value, that way reduce the amount
> > > of
> > > commands and also make the autocomplete a lot more useful since
> > > the
> > > commands shall start with something other than set/get.
> > >
> >
> > OK, I'll make the changes.
> >
> > This would then affect all the meshctl commands.
> >
> > I'll have to rearrange the parameter sequence in some of the
> > commands
> > so I can distinguish between a get and a set.
> >
> > So, where the publish commands currently are
> > set-pub <ele-addr> <pub-addr> <app-idx> .... and
> > get-pub <ele-addr> <model>
> >
> > They would become
> > pub <ele-addr> <model> <pub-addr> .... for set and
> > pub <ele-addr> <model> for get
> >
> > Do I understand this correctly?
>
> Yep, but note that due to shell parsing the .arg string you may need
> to add some parameters to set as optional otherwise the command for
> get will never succeed since it will require all mandatory arguments
> to be given as in the set version. If that becomes impractical and
> cause a lot more code to detect what mode the command shall operate
> then perhaps leave as it is and just revert to pub-set/pub-get to
> make
> autocomplete a little more useful.
>
> > I left the subscription node and database patch separate. I'm on
> > less
> > solid ground here. I basically cribbed the code for bind.
> >
> > I added the UUID to the database as later I'd like to try to re-
> > provision a known unprovisioned node from the database.
> >
> > Steve
> >
I'm not sure I understand the problem.
Some of the get commands require parameters. The same parameters are
also required in the set commands, only more. Currently, they aren't in
the same order. I was going to rearrange the parameters so the set and
get commands have the same parameter sequence. The set command would
just have more. That way I can distinguish between them by the number
of parameters.
Steve
next prev parent reply other threads:[~2017-12-11 16:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 14:58 [PATCH 0/3] mesh: Add configuration commands to meshctl sbrown
2017-12-11 14:58 ` [PATCH 1/3] mesh: Segmentation fails in gatt.c:pipe_write() sbrown
2017-12-12 11:54 ` Luiz Augusto von Dentz
2017-12-11 14:58 ` [PATCH 2/3] mesh: meshctl: Add commands sbrown
2017-12-11 15:12 ` Luiz Augusto von Dentz
2017-12-11 15:40 ` Steve Brown
2017-12-11 15:49 ` Luiz Augusto von Dentz
2017-12-11 16:14 ` Steve Brown [this message]
2017-12-11 22:13 ` Steve Brown
2017-12-11 14:58 ` [PATCH 3/3] mesh: meshctl: Add support for subscriptions in node and database sbrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1513008884.4454.34.camel@ewol.com \
--to=sbrown@cortland.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.