From: Martin Woolley <email@example.com> To: "Linuxfirstname.lastname@example.org" <Linuxemail@example.com> Subject: Comments on the ConnectDevice API function Date: Fri, 22 May 2020 08:22:12 +0000 Message-ID: <MWHPR17MB19671EAD4D74EA7BC5915CA7C5B40@MWHPR17MB1967.namprd17.prod.outlook.com> (raw) 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 address is known, but without first scanning. This is a link layer state transition with the specification allows. BlueZ currently supports this via an API adapter function called ConnectDevice, 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 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 exception 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 ConnectDevice 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 application developer needing to call it just in case this condition applies, catching the BlueZ exception ("Already Exists") and responding by then calling the normal Connect API? An alternative would be to accommodate this special case (not scanned before) in the implementation of the standard device Connect(bdaddr) function or if that makes no sense because Device objects must correspond to previously discovered, physical devices, then at least the adapter ConnectDevice function could take care of the two possible paths and simplify matters for the application developer. Thanks in anticipation. Martin Woolley Senior Developer Relations Manager, EMEA | Bluetooth Special Interest Group, Inc.
next reply index Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-22 8:22 Martin Woolley [this message] 2020-05-22 17:48 ` Luiz Augusto von Dentz 2020-05-27 13:41 ` Martin Woolley 2020-05-27 14:10 ` Szymon Janc 2020-05-27 15:38 ` Luiz Augusto von Dentz 2020-05-27 16:10 ` Martin Woolley 2020-05-27 16:32 ` Martin Woolley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=MWHPR17MB19671EAD4D74EA7BC5915CA7C5B40@MWHPR17MB1967.namprd17.prod.outlook.com \ --firstname.lastname@example.org \ --cc=Linuxemail@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Bluetooth Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-bluetooth/0 linux-bluetooth/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-bluetooth linux-bluetooth/ https://lore.kernel.org/linux-bluetooth \ firstname.lastname@example.org public-inbox-index linux-bluetooth Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth AGPL code for this site: git clone https://public-inbox.org/public-inbox.git