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

[Andrzej Zaborowski]

Hi,

2009/8/10 Denis Kenzior <denkenz at gmail.com>:
>> 2009/8/5 Denis Kenzior <denkenz at gmail.com>:
>> >> mw_set_indicator does the right thing, I missed this fact.  But when a
>> >> mailbox number is set or received from network all clients get a
>> >> PropertyChanged and the new number can be retrieved from the interface
>> >> but only when the store succeeded, previously it would be available
>> >> regardless of MBDN on the card and the writing to card was secondary.
>> >> The number is kind of important if you want to hear the messages.
>> >
>> > So you're right that even if we get an enhanced voice mail notification
>> > message the Mailbox number won't be signaled unless we have the SIM
>> > provisioned with EF-MBI & EF-MBDN.
>> >
>> > The problem is, if we don't have the SIM files available, then the next
>> > time oFono is restarted this information is lost anyway until the next
>> > MWI notification arrives.  So you're back to not being able to dial the
>> > mailbox.
>> >
>> > This is also an issue with the indications themselves.  If we don't have
>> > EF- MWIS provisioned, the information is lost when oFono is restarted.
>> >  So we're now inconsistent between MBDN/MWIS, so maybe we shouldn't
>> > update them either in this case.
>>
>> True.  (or update them both in this case)
>>
>> It would make sense for the providers to resend the MWI information
>> everytime subscriber connects the network and then it would be less
>> problematic in case the information couldn't be written to SIM, but I
>> don't know if they ever do this.
>
> Probably they don't, there are also weird roaming cases to consider, where you
> receive MWI, turn phone off, step on a plane and turn phone on with some other
> network entirely.
>
> Can we make the MWI interface smarter somehow?  Perhaps by not enabling it
> unless at least the EFmwis file is available, or by always storing the EFmwis
> contents on the filesystem?

We could re-use the "sim cache" functions to cheaply save the state of
notifications to filesystem, like in the attached patch (only an
example).  This is not ideal because the SIM might be used in a
different phone or with a different software stack between ofonod
runs, but seems better than not providing the information at all.
Really we don't lose anything even if we don't store the state and
provide the information (MWIS, MBDN) only for the duration of the
ofonod session.

Regards