On Fri, Apr 8, 2011 at 2:57 AM, Torgny Johansson < [email protected]> wrote:
> > From: Dan Williams [mailto:[email protected]] > > 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
_______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
