[PATCH 4/4] Add a MessageWaiting interface to track message waiting indications.

[Andrzej Zaborowski]

Hi,

2009/8/3 Denis Kenzior <denkenz at gmail.com>:
> Ok, now you've taken out the method entirely.  We still want to set the MBDN
> :)  So just add SetProperty that can set the MBDN.

Added.  Note that the provider can also control the EF-MBDN on your
sim through the Enhanced Voicemail notifications (I'll send a patch
later for this and for writing EF-MBDN back to SIM after SetProperty).

>> So the caller can give the exact number of messages (zero or positive)
>> or partial information using one of the constants.
>>
>
> I'm still not sure what the point is, since you just set messages to 1 if
> MWI_MESSAGES_WAITING and to 0 if MWI_NO_MESSAGES_WAITING.  And MWI_UNSPECIFIED
> is just simply ignored.

Yes, this way sms.c gives all the information it has available
(according to specs) in a call to ofono_message_waiting_notify, which
on the message-waiting.c side decides how this information will be
presented to D-Bus clients on MessageWaiting interface (this part
isn't in the specs).  I agree this isn't very useful.

> Perhaps you want to break up the attributes into two:
>
> FooMailWaiting -> True / False
> FooMessages -> Number, with 0 in case we're not sure

We can do that although I think the setting to 0 or 1 when we're not
sure is a good enough approximation?  The 1 being a little lie.

>
> Also, please move all the MWI parsing stuff to message-waiting.c since this
> will allow us to extend the interface more readily.  In particular I'd like to
> eventually support Message ID, Message Calling Line Identity by exposing an
> additional EnhancedMessageInfo interface.
>
> Names are for illustration only at this point:
> EnhancedMessages -> "/modem1/mwi/4344", "/modem1/mwi/2255"
>
> EnhancedMessageInfo Properties:
>
> RetentionDays
> Priority
> CallingParty

Sounds like a good idea.

>> > Can we instead process the different sources from highest to lowest
>> > instead and bail out early?  No sense in calling message_waiting_notify
>> > several times (and possibly emitting spurious signals) when only once is
>> > required.
>>
>> We can but then we won't comply with that 23.040 9.2.3.24.2 above.
>> There's also a tiny possibility someone might send us updates for the
>> different mailboxes (out of the 5 types defined) one using DCS and
>> another one in UDH.  In the attached patch I left this as is and made
>> sure PropertyChanged is only sent from the time callback (bottom half)
>> which was my original intention.  I can still change this.
>
> I still don't understand why we can't do something like:
>
> if sms_contains_enhanced_vm_iei(sms):
>        handle_enhanced_vm_info
>        return
>
> if sms_contains_special_vm_iei(sms):
>        discard = extract_discard_from_iei_data
>        // Quote relevant part of the spec here
>        if mwi_dcs_decode(sms, ... ,dcsdiscard)
>                discard = discard || dcsdiscard
>        return
>
> if mwi_dcs_decode:
>        handle simple DCS MWI
>        return
>
> if "Return Call Message"
>        return

Err, yes we can, but then we don't account for the little corner cases
like the two mentioned:

 * Special Message Indication IEI says discard the message but DCS
says store it.
 * Special IEI says there are 3 emails waiting and DCS says there's a
voicemail message.

>
>> >> +final:
>> >> +     /* Only bother the Message Waiting interface with textual
>> >> +      * notifications that are not to be stored together with other
>> >> +      * Short Messages in ME.  The other messages will be delivered
>> >> +      * to the user through normal SMS store.  */
>> >
>> > It sounds to me like we can completely ignore the text of such messages.
>> >  The network is basically saying: "the text isn't important, the contents
>> > are."
>>
>> Probably, although with the Return Call type of notification there's
>> no other information beside the text.  I left it in the updated patch.
>
> So I still say lets get rid of LastNotificationText entirely.

Ok, removed it.

>  Remember, most
> likely scenario is that carriers will send something like:
>
> .pid = Return Call
> .dcs = mwi dcs
> .uhdi = true
> .udh = contains special iei, contains enhanced iei.
>
> to cover all phase mobiles in some way.
>
> The only case you're really covering here is if we get a pure Return Call
> Message.

Right.

>  This should not happen on any modern network, and  we should not
> give it to the MessageWaiting interface anyway, since there's nothing useful
> it can do with it.

It still gives us one piece of information: the message is concerning
waiting messages.  So perhaps it should be that interface providing
the message and from there it can be displayed on the screen.

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-a-MessageWaiting-interface-to-track-message-wait.patch
Type: application/octet-stream
Size: 24629 bytes
Desc: not available
URL: <http://lists.ofono.org/pipermail/ofono/attachments/20090803/1140aa09/attachment-0001.obj>