Hi, 2009/8/3 Denis Kenzior <[email protected]>: > 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
0001-Add-a-MessageWaiting-interface-to-track-message-wait.patch
Description: Binary data
_______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
