2009/8/3 Denis Kenzior <denkenz(a)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
> 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"
Sounds like a good idea.
> > Can we instead process the different sources from highest to
> > 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 22.214.171.124.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:
discard = extract_discard_from_iei_data
// Quote relevant part of the spec here
if mwi_dcs_decode(sms, ... ,dcsdiscard)
discard = discard || dcsdiscard
handle simple DCS MWI
if "Return Call Message"
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
> >> +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
> > 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.
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
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.