Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <MWHPR17MB19671EAD4D74EA7BC5915CA7C5B40@MWHPR17MB1967.namprd17.prod.outlook.com>
In-Reply-To: <MWHPR17MB19671EAD4D74EA7BC5915CA7C5B40@MWHPR17MB1967.namprd17.prod.outlook.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Fri, 22 May 2020 10:48:44 -0700
Message-ID: <CABBYNZKonvHxnabQsu84rVQEPpou45UgqVUECZ2HoTdd7pWT+A@mail.gmail.com>
Subject: Re: Comments on the ConnectDevice API function
To:     Martin Woolley <mwoolley@bluetooth.com>
Cc:     "Linux-bluetooth@vger.kernel.org" <Linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Martin,

On Fri, May 22, 2020 at 1:25 AM Martin Woolley <mwoolley@bluetooth.com> wro=
te:
>
> Hello
>
> I've recently been working with BlueZ via D-Bus and have a situation whic=
h requires me to be able to connect to a device whose Bluetooth device addr=
ess is known, but without first scanning. This is a link layer state transi=
tion with the specification allows.
>
> BlueZ currently supports this via an API adapter function called ConnectD=
evice, whose status is currently "experimental". From my experience of usin=
g this function, it seems to behave like this:
>
> If the BlueZ instance has not scanned yet, so that the target device is n=
ot known to it, the ConnectDevice call results in scanning taking place and=
 then if the target device is found, it is connected to. Success!
>
> But if scanning has previously been performed, regardless of the state of=
 the actual device (e.g. advertising and ready to accept connections), an e=
xception is thrown with a message whose text value is "Already Exists".
>
> I was wondering if I could influence the design of the API before the Con=
nectDevice experimental status is removed?
>
> I would like to suggest that there should be no need for a special API to=
 connect directly to a device without first scanning. Why burden the applic=
ation developer needing to call it just in case this condition applies, cat=
ching the BlueZ exception ("Already Exists") and responding by then calling=
 the normal Connect API?

I guess the intention was to have the application use the intended API
for devices already present _before_ calling ConnectDevice, so before
entering the address manually the application would enumerate the
existing devices and figure out if that was already present.

> An alternative would be to accommodate this special case (not scanned bef=
ore) in the implementation of the standard device Connect(bdaddr) function =
or if that makes no sense because Device objects must correspond to previou=
sly discovered, physical devices, then at least the adapter ConnectDevice f=
unction could take care of the two possible paths and simplify matters for =
the application developer.

I guess you probably know this but just in case someone look at the
archives it is better that we make some things clearer, while the core
spec allows connecting without scanning D-Bus are intend to be a
higher level API thus why ConnectDevice was not really necessary for a
long time and we just introduced it for qualification purpose or when
there are multiple adapter where one acts as scanner. Also ever since
the introduction of privacy (random addresses) APIs that takes
addresses becomes rather complicated to be used directly, and there
exists ways to scan for a specific address with pattern filtering:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt=
#n122

That said I don't oppose to remove Already Exists error, but we should
be very clear that the use of such API should only be recommended with
users input and does not substitute the likes of Device.Connect.

--=20
Luiz Augusto von Dentz