Hi Chen, On Mon, Dec 5, 2011 at 7:10 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > What do you mean restoring the attribute handles ? Each of the profiles registers its own services when the plugin is loaded, according to the load order (which I assume will not change). There is no guarantee in the load order. As we add more plugins, you can't predict the order the plugins will be loaded. > When a profile registers its attributes, it can specify callbacks for read/write which are actually function pointers. How to you plan to support this? Only attribute *handles* are to be stored (for now). The mapping could be based on service+characteristic UUIDs (but we need to pay attention if we have multiple services with same service and characteristic UUIDs; for this case, I'm not even sure how the client knows which one to use). > In addition, who will be responsible for reloading the database and populating the values (profile plugin or bluetoothd core) ? how do you synchronize them? My suggestion would be to implement this in attrib/gatt-service.c so gatt_service_add() could load attribute handles from storage transparently. This could also avoid changing every profile. Note this is only for *server* roles (e.g. PAS server, TIP server, PXP reporter etc.). I'm not sure what you mean with synchronization. The attribute handles are to be stored when the service is registered (and you can't change them after registration). > Do you have an RFC or a simple design description which will allow reviewing? No. I am not working on this currently. This discussion started from an idea from Santiago to how to handle registration failures (see initial post), to which I responded that we may want first to address attribute handle storage to make sure handles stay the same during device lifetime (until it is factory reset). Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- 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
