Re: SV: Ericsson Support for SMS receive

[Nathan Williams <njw google com>]

On Fri, Apr 8, 2011 at 2:57 AM, Torgny Johansson <torgny johansson ericsson com> wrote:

> From: Dan Williams [mailto:dcbw redhat com]
> 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?

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?)

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.

� � - Nathan