On 03/10/2019 14:04, Luiz Augusto von Dentz wrote: > Well I guess you are forgetting that other users of the GATT may > interfere with plugin which is why we do the claim APIs in the first > place. Okay, I understand your arguments from your perspective, which seems to focus on specific use cases with Desktop Linux. But how do you suppose should application programmers or solution providers access GATT characteristics under Linux in a predictable way then? Not using BlueZ does not seem like a realistic option. Building patched versions of bluetoothd isn't practical either. At the very least there should be a build option to deactivate all plugins, but I think something more flexible would be better. Could it be a user choice? E.g. only claim services which the User has actively connected to and activated that service? In general I don't need to poll the battery status of every device I happened to connect to, even though it might export a Battery service... so I'd consider it more traffic if BAS is polled even though I didn't ask for it. On the other hand on a Bluetooth device I have paired with, something like a Headphone or Keyboard it obviously is the right choice. I hope there is a way to support both use cases. Regards, bruno >> It surely makes sense to provide this more generic API, but I'd argue >> that all services and characteristics should be available via the normal >> GATT-based API using org.bluez.GattCharacteristic1 as well. > > Not if the service has security implication, for instance we don't > want application to be able to access the keys presses coming from a > HoG device, or other things like changing the settings bluetoothd has > configured. > >> One of my clients, for example, uses Linux/bluez as an interface for >> Server-based reading and writing of GATT characteristics of several >> managed devices. So I can read all those UUIDs, but why not the battery >> level? What happens when Bluez learns other GATT services, will their >> characteristics then also disappear? I think there is a strong argument >> for maintaining a generic API for GATT reading/writing characteristics >> independently. > > But there is even a stronger argument if something breaks because the > app access something it shouldn't, even if there are no conflicts > between the plugin the very least it would cause is duplicating the > traffic. > >> I made the following change to the bluetoothd code to get access again >> to all UUIDs, and I would like you to consider to include it upstream to >> enable us to access all characteristics via the normal GATT API: >> >> --- a/src/gatt-client.c >> +++ b/src/gatt-client.c >> @@ -2006,9 +2006,6 @@ static void export_service(struct >> gatt_db_attribute *attr, void *user_data) >> struct btd_gatt_client *client = user_data; >> struct service *service; >> >> - if (gatt_db_service_get_claimed(attr)) >> - return; >> - >> service = service_create(attr, client); >> if (!service) >> return; >> >> Thank you, >> bruno >> >> >> [1] I published parts of that as an open source library: >> https://github.com/infsoft-locaware/blzlib >> >> [2] >> https://stackoverflow.com/questions/49078659/check-battery-level-of-connected-bluetooth-device-on-linux >> >> > >
