Currently, the library is made for one thread making request one after another. But I realised people can ask for having several threads making request at random time, whatever is the application.

The point blocking the multi-threading is the common context to all the call-backs. This problem could be solved by giving specified context (using user_data) to each callback.

Feature specified in the Bluetooth core V4 masterfile, (section 3-G-4) but not implemented.

• See during test that g_attrib_register doesn't make the registration to the BLE device. There is a possibility that g_attrib_unregister doesn't do the unregistration on to the BLE device.
• I added to the event system of BlueZ the storage of UUID, but here there is no protection if several notifications has the same UUID.
• Finally, offer the possibility to activate an auto-callback function on the "service changed" characteristic, to update the handle stocked in the event list of BlueZ.

I didn't have any BLE device available that used included/secondary service. So first of all the function has never been appropriatly tested.

And secondly I wonder if a function to get secondary service are necessary, or if the function to get service is enough ? Since I never experienced this use case.