Re: [RFC] adapter: Add CreateDevice method

Hi Marcel,

On Thursday, 18 January 2018 11:20:03 CET Marcel Holtmann wrote:

Hi Szymon,
=20

quoted

quoted

quoted

quoted

This allows to create Device1 object without discovery. This is need=

ed

quoted

quoted

quoted

quoted

for
some of qualification tests where there is no general discovery upfr=

ont

quoted

quoted

quoted

quoted

and we need to do connection to device with provided address.
=20
Another usecase is for scenario where scanning happen on one control=

ler

quoted

quoted

quoted

quoted

but
connection handling on another.
=20
Implementation wide this results in new temporary device object being
created that if unused will be cleanup just like it would be if found
during discovery session.

=20
so what are the rules around the cleanup? On next discovery it is gone
again, then that might needs to be mentioned.

=20
Those are same rules so it will be gone only if it is left temporary (=

ie

quoted

quoted

Connect() or Pair() was never called). I'll document that.
=20

quoted

quoted

This patch implements bare minimum properties needed for connection -
address and address type. If needed eg. for non-NFC based OOB it cou=

ld

quoted

quoted

quoted

quoted

be
extended with more options.
---
doc/adapter-api.txt | 29 ++++++++++++++++
src/adapter.c       | 96
+++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files change=

d,

quoted

quoted

quoted

quoted

125 insertions(+)
=20

diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 0533b674a..c8f3ce26e 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt

@@ -145,6 +145,35 @@ Methods		void StartDiscovery()

=20
			Possible errors: None
=20
+		void CreateDevice(dict properties) [experimental]
+
+			Creates new temporary device with defined properties.

=20
Why is this not returning the device object path that gets created?
Seems a
waste time cycles to wait for a device showing up later.

=20
I was thinking about that too. I'll make it return object path.
=20

quoted

quoted

+
+			Parameters that may be set in the filter dictionary
+			include the following:
+
+			string Address
+
+				The Bluetooth device address of the remote
+				device. This parameter is mandatory.
+
+			string AddressType
+
+				The Bluetooth device Address Type. This is
+				address type that should be used for initial
+				connection. If this parameter is not present
+				BR/EDR device is created.
+
+				Possible values:
+					"public" - Public address
+					"random" - Random address
+
+			Possible errors: org.bluez.Error.InvalidArguments
+					 org.bluez.Error.AlreadyExists
+					 org.bluez.Error.NotSupported
+					 org.bluez.Error.NotReady
+					 org.bluez.Error.Failed
+

=20
Now what I wonder is that in case of LE, this should actually trigger=

 a

quoted

quoted

quoted

quick scan for that device so that you get advertising data and other
information about the device. We are missing a kernel API for such a
targeted case and that might need fixing as well.
=20
In case of BR/EDR, this might should trigger a connection and SDP
discovery.
=20
Otherwise this is not an API and just a hack to create a device path
object. So you are essentially just doing an =E2=80=9CInjectDevice=E2=

=80=9D instead of

quoted

quoted

quoted

anything real.

=20
Maybe we should just implicitly make it connect to device? That would
keep
things simple and wouldn't require any additional kernel work. If conn=

ect

quoted

quoted

failed we remove device.

=20
that would work as well and since for LE we always scan first, we get t=

he

quoted

advertising data as well. Now the question is if just call it
DiscoverDevice instead. I am reluctant to call it ConnectDevice since
that is a bit overlapping with Device.Connect. And CreateDevice is bad =

as

quoted

well since this is temporary connection in most cases.

actually just trying to connect really only works for BR/EDR. With LE that
would not help us with non-connectable devices. So I am leaning towards
DiscoverDevice that does BR/EDR connect and SDP. And on LE it does an
active scan for that specific device. No connection attempt required on L=

E.

This is explicitly meant for connectable devices so I'd now bother with non-
connectable devices as those are by definition discovered with observation=
=20
procedure.=20

I'm now thinking on method name (was going initially with ConnectDevice but=
=20
you already mentioned that you don't like it:P)

=2D-=20
pozdrawiam
Szymon Janc