From: "michal.lowas-rzechonek@silvair.com" <michal.lowas-rzechonek@silvair.com>
To: "Stotland, Inga" <inga.stotland@intel.com>
Cc: "linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
"jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
"Gix, Brian" <brian.gix@intel.com>
Subject: Re: [PATCH BlueZ v5 1/4] mesh: Add ImportLocalNode API documentation
Date: Wed, 17 Jul 2019 21:47:12 +0200 [thread overview]
Message-ID: <20190717194712.i4dtiwhldq2is2z2@kynes> (raw)
In-Reply-To: <915ea1c10883aaf1e4d42c5a749bfda964b54b51.camel@intel.com>
Hello,
On 07/17, Stotland, Inga wrote:
> I feel like having "object app_root" is unnecessary and also, creates
> some gnarly pathways within the code.
>
> What exactly is the problem for requiring the composition data to be
> part of the import_data? It's just weird to say "oh, it may be there or
> it may be not".
The main issue lies on the application side. In order to properly
Attach(), the application must expose element structure via D-Bus.
If we say that it must also do the same via JSON, to call
ImportLocalNode, it leads to code duplication on the application side.
Moreover, the app still needs to be queried via D-Bus to check that the
passed JSON matches the D-Bus structure - otherwise the app would then
fail to Attach() and the user would be in deep trouble.
> Getting rid of the app_root and mandating the composition to be part of
> the import_data allows:
>
> 1) Avoid checking whether this is a "full" configuration or the
> "minimal" one
I'm not convinced that the "full" configuration is even needed. We
certaintly don't use it in our use case, but it might be required in the
future.
> 2) Efficiently re-use the existing code:
> Adding an API call like this one may be sufficient
>
> mesh_config_import(const char *cfg_dir,
> const uint8_t uuid[16],
> const uint8 *import_data, <import__len>?,
> mesh_config_node_func_t cb,
> void *user_data)
>
> We can just re-factor the code that parses and populates a single node
> from the stored configuration. user_data may contain whatever we need
> to preserve in order to respond to d-bus call.
After refactoring node validation to byte-compare composition data, the
code also becomes significantly simpler, and execution paths for Join(),
Attach(), CreateNetwork() and ImportLocalNode() converge.
I've implemented this validation method on top of this patch-set. I'll
send it as RFC shortly.
regards
--
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
next prev parent reply other threads:[~2019-07-17 19:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 8:36 [PATCH BlueZ v5 0/4] Implement ImportLocalNode D-Bus API Michał Lowas-Rzechonek
2019-07-17 8:36 ` [PATCH BlueZ v5 1/4] mesh: Add ImportLocalNode API documentation Michał Lowas-Rzechonek
2019-07-17 19:36 ` Stotland, Inga
2019-07-17 19:47 ` michal.lowas-rzechonek [this message]
2019-07-17 21:14 ` Gix, Brian
2019-07-18 8:16 ` michal.lowas-rzechonek
2019-07-17 8:36 ` [PATCH BlueZ v5 2/4] mesh: Extract read_* functions in mesh-config-json Michał Lowas-Rzechonek
2019-07-17 8:36 ` [PATCH BlueZ v5 3/4] mesh: Implement ImportLocalNode() method Michał Lowas-Rzechonek
2019-07-17 8:36 ` [PATCH BlueZ v5 4/4] mesh: Convert void pointers to anonymous unions in managed_obj_request:wq Michał Lowas-Rzechonek
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=20190717194712.i4dtiwhldq2is2z2@kynes \
--to=michal.lowas-rzechonek@silvair.com \
--cc=brian.gix@intel.com \
--cc=inga.stotland@intel.com \
--cc=jakub.witowski@silvair.com \
--cc=linux-bluetooth@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox