Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 27 Jun 2019 21:51:27 +0200
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?
Message-ID: <20190627195127.payxcdeexiamsi24@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
        "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20190625143855.29889-1-jakub.witowski@silvair.com>
 <1561568468.22940.16.camel@intel.com>
 <14abe0f2129a2334d32aa14f2167380a5208880b.camel@intel.com>
 <CAMCw4t3pXTbtt05RD694jzF_MNT_J9dcFMtA7iuD4ujZT9FDbg@mail.gmail.com>
 <1561660267.7802.29.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1561660267.7802.29.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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