Hi Alfonso, > I need to connect to a non-standard remote GATT service. We don't plan > to submit the resulting client code for the time being (it would be of > little interest for the general public), for which it would be good to > keep it as decoupled as possible from bluetoothd. > > As I see it, I have two options: > > 1) Create a BlueZ plugin. bluetoothd supports external plugins through > shared objects but that's not enough to decouple them from bluetoothd: > > * Is bluetoothd's API supposed to be respected across versions? > * Even if the answer is true, which I doubt, without a decoupled set > of header files which the plugin can use, I don't see a way to build > it outside of BlueZ's tree. the internal plugin API is not guaranteed. You can build an external plugin and the daemon will load it. That is technically possible. > 2) Use the experimental D-Bus GATT API. > > Even if the API is likely to change, it would allow to build and > implement the client in a separate process. That is the intention here. We want to explicitly allow 3rd party application to operate as GATT client and GATT servers. So that is the way to go. > Its documentation (doc/gatt-api.txt) made me assume that the API would > be automatically exposed for all services in remote devices since we > discover them when pairing or connecting to a device for the first > time. However, that doesn't seem to be the case. Is there a reason not > to do it? You might have to start the daemon with -E flag. I am also not sure that it is fully hooked up yet. However that would an easy fix I guess. Regards Marcel -- 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
