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;
From:   Martin Woolley <mwoolley@bluetooth.com>
To:     "Linux-bluetooth@vger.kernel.org" <Linux-bluetooth@vger.kernel.org>
Subject: Comments on the ConnectDevice API function
Thread-Topic: Comments on the ConnectDevice API function
Thread-Index: AdYwEgyeeFpEUtO5S3yfGGFiF3wWKw==
Date:   Fri, 22 May 2020 08:22:12 +0000
Message-ID: <MWHPR17MB19671EAD4D74EA7BC5915CA7C5B40@MWHPR17MB1967.namprd17.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 55239f9f-35bd-4c92-b93f-08d7fe293ad9
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2020 08:22:13.0086
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e4e0fec5-fc6c-4dd6-ae37-4bdb30e156b9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qFGuroxT9F8VUd8MGZe97QXTrkyBM/PFLMLj0o2Ro8B0LKoxtWfZTb8twWSnM1wzZzY5oPEQ2BPBvonr708wmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR17MB1598
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-bluetooth.vger.kernel.org>
X-Mailing-List: linux-bluetooth@vger.kernel.org

Hello

I've recently been working with BlueZ via D-Bus and have a situation which =
requires me to be able to connect to a device whose Bluetooth device addres=
s is known, but without first scanning. This is a link layer state transiti=
on with the specification allows.

BlueZ currently supports this via an API adapter function called ConnectDev=
ice, whose status is currently "experimental". From my experience of using =
this function, it seems to behave like this:

If the BlueZ instance has not scanned yet, so that the target device is not=
 known to it, the ConnectDevice call results in scanning taking place and t=
hen if the target device is found, it is connected to. Success!

But if scanning has previously been performed, regardless of the state of t=
he actual device (e.g. advertising and ready to accept connections), an exc=
eption 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 Conne=
ctDevice experimental status is removed?=20

I would like to suggest that there should be no need for a special API to c=
onnect directly to a device without first scanning. Why burden the applicat=
ion developer needing to call it just in case this condition applies, catch=
ing the BlueZ exception ("Already Exists") and responding by then calling t=
he normal Connect API?=20

An alternative would be to accommodate this special case (not scanned befor=
e) in the implementation of the standard device Connect(bdaddr) function or=
 if that makes no sense because Device objects must correspond to previousl=
y discovered, physical devices, then at least the adapter ConnectDevice fun=
ction could take care of the two possible paths and simplify matters for th=
e application developer.=20

Thanks in anticipation.

Martin Woolley=20
Senior Developer Relations Manager, EMEA=A0 |=A0 Bluetooth Special Interest=
 Group, Inc.