On Thu, Aug 13, 2015 at 9:51 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Jakub, > > On Wed, Aug 12, 2015 at 9:36 PM, Jakub Pawlowski <jpawlowski@xxxxxxxxxx> wrote: >> This patch changes how gatt database for paired devices is stored between >> restarts of bluetoothd. Right now only definition of services is stored. >> After applying this patch whole gatt database will be stored/restored. >> >> Storing whole database can have big impact on reconnection time for paired >> devices, because full discovery can take up to 10 seconds. > > There is a TODO for this but it seems that the documentation under > doc/settings-storage.txt outdated. I believe the preferred way to > store is a binary format under cache so the attributes can be > persisted even if the device info is not stored which is the same > design we use for SDP records, Current policy for LE devices is to store only Service definitions for ONLY paired devices. I think that storing GATT database for unpaired devices, especially ones that have rotating MAC address doesn't really benefit too much, it'll change every 15 minutes and have to be re-discovered leaving unnecessary mess in cache. Is keeping cache for paired devices only fine for you ? Also when it comes to format for storing data, I'd like to use functions from shared/gatt_db to restore GATT gatt_db_insert_service gatt_db_service_add_included gatt_db_service_insert_characteristic gatt_db_service_insert_descriptor just to make sure everything will get wired properly, and will work fine if implementation of those methods change (I also don't want to reimplement what they already do). I'll change implementation to store properties and uuids in binary format, but I'd prefer not to implement serialization to make one line per attribute. Will that be fine? > note that the code will perform a Read > By Group Type regardless if the database is empty or not to validate > the services on every connection so we need to update the cache every > time an attribute changes. Yes, I'm aware of that. That's actually good for devices that have "Service Changed" characteristic badly implemented, or when something just goes wrong. > > > -- > Luiz Augusto von Dentz -- 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
