Hi Johan,
On Wed, Jan 18, 2012 at 9:49 AM, Anderson Lizardo
<anderson.lizardo@xxxxxxxxxxxxx> wrote:
> Hi Johan,
>
> On Wed, Jan 18, 2012 at 8:17 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote:
>> Hi Claudio,
>>
>> On Fri, Jan 13, 2012, Claudio Takahasi wrote:
>>> +Proximity Reporter hierarchy
>>> +===========================
>>> +
>>> +Service used by Proximity Path Loss and Find Me. Allows per device
>>> +alert level handling.
>>> +
>>> +Service org.bluez
>>> +Interface org.bluez.ProximityReporter
>>> +Object path [variable prefix]/{hci0,hci1,...}
>>> +
>>> +Methods
>>> +
>>> +
>>> +Signals ImmediateAlertLevelChanged(object device, string value)
>>> +
>>> + This signal indicates that Immediate Alert Level
>>> + characteristic was changed by the remote device.
>>> + Values: "none", "mild", "high".
>>> +
>>> +Properties
>>
>> Shouldn't ImmediateAlertLevel and LinkLossAlertLevel be defined as
>> properties and then you'd have PropertyChanged instead of these custom
>> signals?
>
> Initially, we discarded one approach where we could have Properties on
> the _device_ object path, because we would need to monitor each new
> created device, check if it has the Immediate/LinkLossAlertLevel
> property on the ProximityReporter interface, and if so, listen to the
> PropertyChanged signal. This seems too much overhead IMHO.
>
> Unless you are proposing keeping the interface and properties on the
> adapter object path? In this case, we will lose the information about
> the peer device which issued the alert. I'm unsure if this is a big
> problem or not (given that the alert is "global" to the Proximity
> Reporter, not a per peer state).
>
> On the other hand, this "custom signal" approach allows to have only
> one (or two) listener, no matter how many devices are connected to the
> reporter, and still know which peer triggered the alert.
>
> One benefit of knowing which device triggered the alert, is to have
> custom alerts (e.g. different sounds) for each device, or if the
> reporter has a display, show which device is making alerts.
>
> Any ideas?
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
I will send the proposal that you are suggesting to collect more
feedbacks, it is the RFC "proposal "1 sent some weeks ago.
Complementing what Lizardo wrote, use the device object path is not
aligned with the current APIs.
PropertyChanged for ImmediateAlertLevel or LinkLossAlertLevel will be
sent when the remote device(GATT client) writes a new value in the
alert level characteristic of the local GATT service(Link Loss or
Immediate Alert). If this concept of sending PropertyChanged signal
using the device's object path for an action triggered by the remote
is clear to everyone we can continue this approach.
BR,
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
