Re: SV: Ericsson Support for SMS receive

[Marcel Holtmann <marcel holtmann org>]

Hi Nathan,

>         
>         > Sure, that sounds fine, unless we decide to just ignore SIM
>         > storage completely and use local storage like Marcel
>         suggests.
>         
>         
>         For me, just using ME would be fine. Nathan?
> 
> 
> ME-only works for me.
>  
>         > I believe the original idea was that SmsReceived would be
>         > emitted to every unique SMS reported, no matter whether that
>         > SMS was complete or partial.  Then, when the full SMS was
>         > received and reconstructed from all its parts, the Completed
>         > signal would be emitted.  If the message was single-part,
>         > both SmsReceived *and* completed would be emitted for that
>         message.
>         
>         
>         Right, so for the final part (regardless if the sms consists
>         of more than one message or not) you'll 
>         always send both?
> 
> 
> This was my interpretation of the API as well.
> However, I'm a little bit unclear on what the index numbers should be
> in the case of multipart messages. The different parts will have
> different low-level index numbers; should we be concealing those and
> only reporting up the index number of the first part we received?

you do not have index numbers if these are forwarded to the ME right
away. The index numbers are storage numbers on the SIM card.

> That is, does this seem like the correct sequence:
> Receive "Part 1 of 3" as SMS index 5. Generate signal "SmsReceived",
> index=5, complete=false.
> Receive "Part 2 of 3" as SMS index 6. Generate signal "SmsReceived",
> index=5, complete=false.
> Receive "Part 3 of 3" as SMS index 7. Generate signal "SmsReceived",
> index=5, complete=true; generate signal "Completed", index=5,
> complete=true.
> 
> 
> (And if this is the case, do we respect Get or Delete operations on
> index 6 or 7? How about on index 5 before we're received all three
> parts?)

Same as above, if you do not store them on SIM, then there are no Get or
Delete operation.

> If we wanted to avoid maintaining this index mapping, the alternative
> would seem to be to include the "Part N of M" metadata in the message
> dictionary and make it a problem for the client to solve.

If you seriously consider sending out message parts to the applications,
you are doing something wrong. You do not want the UI having to deal
with the reassembly of fragments. There is no way that any UI gets this
right any time soon. This is a highly complicated problem.

You guys realized all the possible variation that are coming into play
with messages with user data headers and things like different alphabets
and of course status reports etc.

Regards

Marcel