DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1AE8420854
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Subject: Re: [PATCH BlueZ] doc: Initial Bluetooth Mesh API
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <c2485caca3145e8aaaa1a8396b294b46a55b97e3.camel@intel.com>
Date:   Sun, 11 Nov 2018 11:07:08 +0100
Cc:     Johan Hedberg <johan.hedberg@gmail.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        Brian Gix <brian.gix@intel.com>
Content-Transfer-Encoding: 8BIT
Message-Id: <DFAA7E3E-A9CB-40DD-A959-FA23DE8B41F5@holtmann.org>
References: <20181107004950.9153-1-inga.stotland@intel.com>
 <4DBB63ED-41C4-4F27-B2BC-1ADB090B1656@gmail.com>
 <c2485caca3145e8aaaa1a8396b294b46a55b97e3.camel@intel.com>
To:     "Stotland, Inga" <inga.stotland@intel.com>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Inga,

>> At first glance this looks quite good to me, just some cosmetic
>> comments:
>> 
>>> On 7 Nov 2018, at 2.49, Inga Stotland <inga.stotland@intel.com>
>>> wrote:
>>> +Service	org.bluez.mesh1
>> 
>> I don’t think we’ve had the habit of versioning well-known bus names
>> so far. Or did you see this somewhere? So I’d just leave away the
>> version here.
>> 
> 
> From D-Bus Api Design Guidelines: (
> https://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning):
> 
> "In summary, version numbers should be included in all service names,
> interface names and object paths:
> 
>    com.example.MyService1
> 
>    com.example.MyService1.InterestingInterface
> 
>    com.example.MyService1.OtherInterface
> 
>    /com/example/MyService1/Manager
> 
>    /com/example/MyService1/OtherObject
> "
> 
> I chose to do the name versioning based on the official guidelines.
> However, if we want to preserve the historical bluez approach, I don't
> mind changing it.

so a long time ago, I looked at this and considered it pointless. It a total bloat that serves no practical purpose. Versioning the interface names makes sense since it allows to upgrade an interface and remove method or change its behavior if that would ever be really needed.

Reality is that we will never write a second daemon for version 2 and that is what versioning essentially implies here. Everything is versioned in a manor that service1 and service2 are totally independent. However what is the point in a technology like Bluetooth. 90% of the methods, properties and behaviors will not change. So we are duplicating everything for 10% or less optimization. That just makes no sense.

>>> +			PossibleErrors:
>>> +				org.bluez.mesh1.Error.Failed,
>>> +				org.bluez.mesh1.Error.Canceled,
>>> +				org.bluez.mesh1.Error.InvalidArguments
>>> +				org.bluez.mesh1.Error.Timeout
>> 
>> We’ve never versioned errors either, or did you see this done
>> somewhere? So just leave it out from here.
> 
> So you can see a number of services following the above mentioned D-Bus 
> API Guidelines by running d-feet: e..g., org.freedesktop.GeoClue2 or
> org.freedesktop.UDisks2 or org.fedoraprojectFirewallD1

Blindly following some recommendations is dangerous and that is what is happening here. It is blindly following or the project is implement in a memory eating language like Python in the first place.

Regards

Marcel