Hi Marcin, On Wed, Apr 9, 2014 at 4:06 AM, Marcin Kraglak <marcin.kraglak@xxxxxxxxx> wrote: > This is proposal how gatt database implementation could look and > how it can be used in Android. Current implementation contains: > - create/destroy gatt_db > - adding services, with given number of handles. This function returns > service attribute andle > - adding characteristics, descriptors and included services > - function to start/stop service - it will be used when we expose services > to client > > Next steps in gatt_db implementation should be: > - handling read/write callbacks > - handling attribute's permissions > - now we just increment available handle. We should check if we have free handles > between existing services > > Comments are welcome > Marcin Kraglak IMO, the database could be used to represent both: local and remote. I am not familiar with Android BlueZ storage, does it make sense to have a common storage for attributes declarations (remote attribute caching)? When the GATT service is local, we need to store the mapping between handles and applications(or UUIDs). Remember that CCC storage is per device. For remote attribute caching, we will need to store the declarations only. Regards, Claudio -- 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
