Re: [RFC BlueZ] doc: Introduce Alert API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gustavo,

On Wed, Aug 15, 2012 at 12:27 AM, Gustavo Padovan <gustavo@xxxxxxxxxxx> wrote:
>> +Currently, there are two different GATT server profiles that depend on
>> +receiving alerts or notifications from the platform: Phone Alert Status (PASP)
>> +and Alert Notification (ANP). Additionally, PASP is very specific to mobile
>> +phones, and also allow limited control to alerts (i.e. mute once, or switch to
>> +a silent mode).
>> +
>> +This document presents a unified API that allows to register,
>
> Is there some missing text here?

Yes, I will fill the missing text on next revision. I also have minor
fixes to the alert categories.

>> +
>> +Alert hierarchy
>> +===============
>> +
>> +Service              org.bluez
>> +Interface    org.bluez.Alert
>> +Object path  /org/bluez
>> +
>> +Methods              void RegisterAlert(string category)
>> +
>> +                     Register a new alert category. This means the
>> +                     application will be responsible for notifying BlueZ of
>> +                     any alerts of that category, using the Alert() method.
>> +
>> +                     Supported categories: generic, email, news, call,
>> +                     missed_call, sms_mms, voice_mail, schedule,
>> +                     instant_message, ringer, vibrate, display.
>> +
>> +                     Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> +             void RegisterAgent(string category, object agent)
>> +
>> +                     Register a new agent for the alert category. The agent
>> +                     object methods to be called depend on the category. The
>> +                     currently supported category is "ringer", with methods
>> +                     MuteOnce() and SetRingerMode().
>> +
>> +                     Possible Errors: org.bluez.Error.InvalidArguments
>
> If I got this right you RegisterAlert() and then RegisterAgent() in the
> sequence, right? Why can't you merge both calls into one.

Originally, the agent was only necessary for the "ringer" category.
But after further thinking, looks like we can use it to update the
"new alert" and "unread alert" counts necessary for ANP. I will
prepare an updated document and send ASAP.

>> +
>> +             void NewAlert(string category, string description)
>> +
>> +                     Notify BlueZ of a new alert for the given category. The
>> +                     description can be sender name, called ID, title, or
>> +                     other information specific to the alert. For ringer,
>> +                     vibrate and display categories, valid descriptions are
>> +                     "active" and "not active".
>
> The way I understand it I see many NewAlert() calls happening almost at the
> same time. Isn't possible to pass a dict with many {string category, string
> description} inside?

It is not clear from the description above (I will improve it), but
for categories like "email" that can have many messages received after
a sync, only a single NewAlert() call is made. The description is for
the last e-mail sent. So the event is actually a single one: "you got
N e-mails, and the sender for the last one is ...". The same applies
to any alerts which have multiple items.

>
>> +
>> +                     Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> +             void UnreadAlertCount(string category, uint16 count)
>> +
>> +                     Some services (like SMS and e-mail) keep track of
>> +                     number of unread items. This method allows to update
>> +                     this counter, so peer devices can read it using Alert
>> +                     Notification Profile.
>> +
>> +                     Note that just calling NewAlert() will not implicitly
>> +                     increment the unread count for a category. The
>> +                     application must call this method to increase or
>> +                     decrease the unread counter.
>
> Is there a good reason for not increment the count on NewAlert()?

There are two counts supported by the ANP profile: "Unread Alert
count" and "New Alert count". I'll try to explain here, but I
suggesting reading sections 1.7.2, 1.7.3, 4.1.2 and 4.1.3 from
ANS_SPEC_V10.pdf. These counts are per category.

Unread Alert count is only useful to some categories, like SMS and
e-mail, that have the concept of "unread message". It may
increase/decrease depending on user interaction with the host UI (e.g.
marking messages as read/unread, deleting messages etc.)

New Alert count is used to keep track of how many alerts are not yet
acknowledged by the user. It is also applicable to SMS/email, and all
other categories. E.g. two calendar events on the same day, and none
of them were opened by the user, will increase this count by two.

As mentioned above, we can use the zgent to have better tracking of
these counts. This would avoid the need for this method, and instead
BlueZ could request for the up-to-date alert counts from the e-mail
application (for example). I will send soon a v2 of this document.


Thanks for your comments!

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
--
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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux