Hi Claudio, > If the remote supports both services, there is no way in the > client(Proximity plugin) to figure out which scenario is happening. > The upper layer(app external to BlueZ) implements the logic to control > the ImmediateAlertLevel. My suggestion are: > 1) add a new property ImmediateAlertTimeout The problem that I see with this new Timeout is that both Proximity and Findme app - above Bluez have to have the intelligence of knowing what services are supported on the remote side and then setting this level accordingly. This can further complicate such apps as these may not be standard profile applications and may be different from LE stacks where both the proximity and FindMe profiles are implemented pretty independently. > 2) or split ImmediateAlertLevel into: FindMeLevel and PathLossLevel > mapping into the same remote characteristic. This would need immediate Immediate alert to propogate to both such levels(FindMe/PAthLoss) from a remote side. May not be that bad except pushing extra logic into higher level apps. But still may be more appealing than the timeout complexities of approach (a). > Opinions? Would suggest (b) except that what happens to existing ImediateAlertLevel timeout. Who shall now decide to disconnect the ATT connection for FindMeLevel and retaining it for PathLoss. May be we need to export ATT disconnect too as a property in this case? Thanks, Arun -- 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
