linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "michal.lowas-rzechonek@silvair.com"  <michal.lowas-rzechonek@silvair.com>
To: "Gix, Brian" <brian.gix@intel.com>
Cc: "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
	"Stotland, Inga" <inga.stotland@intel.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: Was: mesh: Added ImportLocalNode call with its API --> Multiple Methods?
Date: Thu, 27 Jun 2019 21:51:27 +0200	[thread overview]
Message-ID: <20190627195127.payxcdeexiamsi24@kynes> (raw)
In-Reply-To: <1561660267.7802.29.camel@intel.com>

Hi everyone,

On 06/27, Gix, Brian wrote:
> I am starting to think we may need multiple methods here to deal with
> the desired use cases:

I don't like this. Back in the day we discussed that we'd like to avoid
D-Bus API bloat...

> * ImportNodeProvData()
> (...)
> The daemon method would perform a GetManagedObject of the calling
> application, to create a node.json with all of the Composition data,
> elements, models, features, etc.

While the initial idea was indeed about importing the whole node,
including configuration, models etc., during implementation we figured
that the reason to do it is to eventually Attach() to such a node - it
doesn't make sense to import something you wouldn't use.

If so, then you need to have an appropriate application anyway, which
the daemon can simply query for all the needed info, as it does at the
moment during Join() and CreateNetwork() calls. This nicely fits into
REQUEST_TYPE processing in get_managed_objects_cb().

This results in smaller API and *significantly* simpler code. As you
mentioned, doing a full migration is complicated.

> * MigrateNode()
> This method would be what Inga and I had originally envisioned for the
> ImportLocalNode() call... It would contain *all* the information that
> a pre-existing node had... including preconfigured pub/sub, features,
> Sequence value that reflected that this node already existed elsewhere
> on the mesh, but was simply being migrated to this device, etc.

The application can do all the configuration using loopback Config
Server messages, so I don't think we need a Migrate() call at all. The
application already receives current node configuration when
Attach()ing, so it can determine if something needs to be reconfigured.

And again, you would need an Attach()able application anyway, so all the
information would need to be duplicated in application's D-Bus
interfaces and in the JSON passed to Migrate() call. This seems like a
violation of DRY principle.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

  parent reply	other threads:[~2019-06-27 19:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25 14:38 [PATCH v2] mesh: Added ImportLocalNode call with its API Jakub Witowski
2019-06-26 17:01 ` Gix, Brian
2019-06-26 17:53   ` Stotland, Inga
2019-06-26 18:37     ` Jakub Witowski
     [not found]     ` <CAMCw4t3pXTbtt05RD694jzF_MNT_J9dcFMtA7iuD4ujZT9FDbg@mail.gmail.com>
     [not found]       ` <1561660267.7802.29.camel@intel.com>
2019-06-27 19:51         ` michal.lowas-rzechonek [this message]
2019-06-28 14:29           ` Was: mesh: Added ImportLocalNode call with its API --> Multiple Methods? Gix, Brian
2019-07-01  9:20             ` michal.lowas-rzechonek
2019-07-01 15:57               ` Gix, Brian
2019-07-02  5:43                 ` Stotland, Inga

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=20190627195127.payxcdeexiamsi24@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;
as well as URLs for NNTP newsgroup(s).