Anderson, > -----Original Message----- > From: Anderson Lizardo [mailto:anderson.lizardo@xxxxxxxxxxxxx] > Sent: Thursday, October 27, 2011 4:03 PM > To: Luiz Augusto von Dentz > Cc: Ganir, Chen; Mat Martineau; Claudio Takahasi; linux- > bluetooth@xxxxxxxxxxxxxxx; bgix@xxxxxxxxxxxxxx; ingas@xxxxxxxxxxxxxx > Subject: Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications > > Hi, > > On Thu, Oct 27, 2011 at 9:57 AM, Anderson Lizardo > <anderson.lizardo@xxxxxxxxxxxxx> wrote: > > But, I don't see why have these (writable?) D-Bus properties if we > > already have RegisterCharacteristicsWatcher(). Are you suggesting > that > > confirmations (for indications) should be sent manually by each D-Bus > > client? Too error-prone IMHO. > > To clarify, the question above was to Chen, not to Luiz. > Characteristics have the ability to be notified or indicated, according to the profile requirements. We need to reflect those capabilities to the user, which can decide whether the characteristic will be notified or indicated. The bluetoothd will take care of the indication return code, and the watcher will be signaled with the existing mechanism. Would you rather see the register watcher get a second parameter to tell it the correct method, and change the properties to CanNotify, CanBroadcast to indicate the characteristic capability only (according to the char properties and availability of client char config descriptor)? If this is the case, than we may implicitly force notify or indicate only, not both of them, although the spec does not prohibit such behavior, and manage the watcher method internally. 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
