On Wed, Oct 6, 2010 at 6:43 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Claudio, > > On Wed, Oct 06, 2010, Claudio Takahasi wrote: >> Initial implementation of per client attribute configuration for the >> attribute server. Notification and indication shall be sent to the peer >> only if Client Characteristic Configuration bit field is set. >> --- >> ÂTODO        Â|  Â7 -- >> Âsrc/attrib-server.c | Â194 +++++++++++++++++++++++++++++++++++--------------- >> Âsrc/storage.c    |  44 ++++++++++++ >> Âsrc/storage.h    |  Â4 + >> Â4 files changed, 184 insertions(+), 65 deletions(-) > > I feel a bit conflicted about this one. Do we really want to have a > generic storage for all characteristics? I'd think that it'd make sense > to let each service implementation take care of how to store their state > persistently (if it needs to be done at all). > > Would it be possible for you to create a patch that fixes the > notification sending to clients that haven't subscribed for them but > leaves out the storage stuff? > > Johan > Hi Johan, "clientconfig" file stores the <<Client Characteristic Configuration>> attribute only. Each characteristic declaration can have this optional attribute. The file format is: MAC#handle xxxx, where the handle is the <<Client Characteristic Configuration>> handle. Only <<Client Characteristic Configuration>> and <<Server Characteristic Configuration>> descriptors are writeable. If you want to test this feature, my suggestion is to push this code upstream and move it to the service implementation if necessary in the future. Currently, we don't have this API/interface between the attrib server and service implementation, this is the reason why I implemented the storage inside the attrib server. IMHO, the attribute server can manage indications, notifications and broadcasting, otherwise we will duplicate the code in the services implementations. I gonna send another patch to disable the automatic notification/indication in the sample server and it is up to you to decide which one to apply. 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
