Anderson, > -----Original Message----- > From: Anderson Lizardo [mailto:anderson.lizardo@xxxxxxxxxxxxx] > Sent: Monday, December 05, 2011 12:56 PM > To: Ganir, Chen > Cc: Santiago Carot; linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] Provide return status in gatt_service_add > function > > Hi Chen, > > On Sun, Dec 4, 2011 at 2:51 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > > How do you ensure that? Do you assume that all servers will always > initialize at bluetoothd startup, and always in the same order? Who's > responsibility is it to send out the "service changed" notification > when something changed? What is the proposed logic for this ? > > To make sure the handles do not change between bluetoothd restarts > (and is not dependent on any loading order), we need to save/restore > attribute handles, like is done for other BlueZ parts. > > "Service Changed" is not necessary to be sent if attribute handle > storage is implemented. We have no plans to implement "Service > Changed" now, but feel free to send patches :) > > Regards, > -- > Anderson Lizardo > Instituto Nokia de Tecnologia - INdT > Manaus - Brazil 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). 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? In addition, who will be responsible for reloading the database and populating the values (profile plugin or bluetoothd core) ? how do you synchronize them? Do you have an RFC or a simple design description which will allow reviewing? Thanks, Chen Ganir. Thanks, Chen Ganir -- 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
