Hi, 2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx>: > Hi Vincent, > > On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <scheib@xxxxxxxxxx> wrote: >> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz >> <luiz.dentz@xxxxxxxxx> wrote: >>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@xxxxxxxxxx> wrote: >>>> I just ran into this issue again (being blocked from accessing a standard >>>> GATT service) when using bluez. I had an application accessing GATT >>>> objects, and also the generic_access service. ... >>> >>> Well the general idea was to block access if there is a plugin already >>> handling a certain service. Now you seem to be claiming this shouldn't >>> be the case and any service can be accessed simultaneously by a plugin >>> running in daemon process and an application, but I don't think this >>> is always true and in some cases they may conflict, or just generate >>> duplicated traffic. >> >> Correct. Bluetooth devices are all required to have a generic_access >> service, and I believe applications should be able to use the GATT >> protocol to interact with that service. I think that the current >> approach bluez has taken of trying to abstract this is a mistake. >> There doesn't seem to be value added by doing so, but there is harm in >> creating additional ways to interact, harming portability and >> requiring more attention and custom code by application developers. > > Well you seem to forget that there are various ways to get the name, > not only GATT. In fact the GAP Service over GATT is just the tip of > the iceberg, since GAP define the connection procedures which has very > little to do with this service, and when it comes to GAP procedures we > do need to know the Name of the devices to display to the user and > that may come from advertisements, inquiry results or from Read Name > command so we can cache the name so we can display it even when not > connected. So if you arguing that the stack should not deal with this > service I would have to disagree. > In my opinion, it's nice that the system tries to maintain a cache using various methods to be able to show the name to the user even when the device is disconnected. However that should not imply that it shouldn't be possible to read the name characteristic directly from an application. There are many reasons why one thinks the name is old and needs to be refreshed; for example if you use a smartphone as GATT server where you easily can change both GATT server and name, or if you do a firmware update and reboot the device the name may change as well. If there is no way to force the system to reload the name then it should definitely be possible to read it directly. This is how Android's implementation works and I guess no one has complained about it. Also when you want to build a Bluetooth library on top on another Bluetooth library it's never fun when each platform has its own restrictions that probably was intended to simplify for the users but in practice often misses special cases leading to incompatibility problems. >>> Perhaps for GAP service itself it is fine to allow applications to >>> access it, the problem is if we allow the application to set the name >>> like you want does it notifies that do the daemon as well? >> >> Yes. The same way multiple applications should be able to receive >> notifications for one device. > > Except that org.bluetooth.characteristic.gap.device_name excludes > notification support: > > https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml I would guess the spec writers didn't really think about what should happen when the name gets updated. iOS actually "takes up/waste" one round trip in each start of connection to read the name characteristic in order to always try to have the latest. Emil -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
