Re: SV: Ericsson Support for SMS receive
On Fri, 2011-04-08 at 10:56 -0400, Nathan Williams wrote: > 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. > > > Or in the other memory spaces. So far we've been discussing (in the > language of 3GPP TS 27.005) +CPMS="ME" versus +CPMS="SM"; both > involve storage somewhere below ModemManager, index numbers, and > get/delete. It sounds like you're introducing the distinction between > +CNMI=1 and +CNMI=2 notifications. That might be useful, but it's an > implementation detail. At any rate, it sounds like you're firmly in > the camp that the numbers in the API should be synthetic rather than > matching the low levels. I believe the original intent was that these would by synthetic index numbers assigned by ModemManager for the duration of the MM run, ie they would *not* be persistent across MM invocations or hotplug of the device. Thus, the index # refers to the _entire_ message instead of each part. Internally MM would do something to map the SIM indexes to external indexes. We should keep the API for this stuff at a higher level to enable much simpler client programming, and have MM hide all this multipart complexity if we can. Dan > > - Nathan > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
Hi Nathan, > 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. > > > Or in the other memory spaces. So far we've been discussing (in the > language of 3GPP TS 27.005) +CPMS="ME" versus +CPMS="SM"; both > involve storage somewhere below ModemManager, index numbers, and > get/delete. It sounds like you're introducing the distinction between > +CNMI=1 and +CNMI=2 notifications. That might be useful, but it's an > implementation detail. At any rate, it sounds like you're firmly in > the camp that the numbers in the API should be synthetic rather than > matching the low levels. I am not talking about storage at all. You need to let the modem deliver the messages to the ME aka host. And I am in the camp of no index numbers. If you need them, then you sooner or later you will make it pretty hard for the user interfaces. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
> > 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. > Or in the other memory spaces. So far we've been discussing (in the language of 3GPP TS 27.005) +CPMS="ME" versus +CPMS="SM"; both involve storage somewhere below ModemManager, index numbers, and get/delete. It sounds like you're introducing the distinction between +CNMI=1 and +CNMI=2 notifications. That might be useful, but it's an implementation detail. At any rate, it sounds like you're firmly in the camp that the numbers in the API should be synthetic rather than matching the low levels. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
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 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
On Fri, Apr 8, 2011 at 2:57 AM, Torgny Johansson < torgny.johans...@ericsson.com> wrote: > > From: Dan Williams [mailto:d...@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 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: SV: Ericsson Support for SMS receive
> -Original Message- > From: Dan Williams [mailto:d...@redhat.com] > Sent: Thursday, April 07, 2011 12:16 AM > To: Torgny Johansson > Cc: Jason Glasgow; Eric Shienbrood; Trond Wuellner; Jonas > Sjöquist; Malin Gustafsson; Nathan Williams; > ma...@menubar.gnome.org; networkmanager-list@gnome.org > Subject: Re: SV: Ericsson Support for SMS receive > > On Mon, 2011-03-21 at 17:20 +0100, Torgny Johansson wrote: > > Hi! > > > > CCing NetworkManager mailing list. I'm sorry that the > thread below is not formatted the way you like it but I'm > keeping it below for reference. > > > > The discussion is about sms support in ModemManager. I've > started implementing it a bit but ran into issues. > > Excellent! > > > I think that a SetStorageLocation method as suggested by > Eric would be sane to add. And have that mirror the CPMS > command as Jason suggested. > > 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? > > > Should I still include the mem-type in SmsReceived signal? > Or should we assume that the caller takes care of setting the > storage correctly? The same question is valid for the SmsGet > method (and delete). > > I guess it depends on the decision above... > > > About the SmsReceived vs Completed signals, I interpreted > it as the SmsReceived signal is emitted for all sms and for > the final sms _both_ the SmsReceived and Completed signals > are emitted. I don't have the code available right now > though, so I'll have to look at it again later. > > 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? /Torgny > > > Another issue is how to handle the completed flag in the > SmsReceived signal and the Completed signals. I suppose one > have to parse the pdu to be able to tell? > > Yeah, likely. There's a bunch of charset handling code in MM > already, I did the GSM charset work last year (minus the > special codepage handling via escapes) so we can extend that. > But PDU mode needs to be implemented. > > Dan > > > Regards > > Torgny > > > > > > Från: Jason Glasgow [jglas...@google.com] > > Skickat: den 21 mars 2011 15:32 > > Till: Eric Shienbrood > > Kopia: Torgny Johansson; Jonas Sjöquist; Malin Gustafsson; Trond > > Wuellner; Nathan Williams > > Ämne: Re: Ericsson Support for SMS receive > > > > Hi Torgny, > > > > I'd like to move this discussion to the nm list, but before > I do so I want to make sure that you are okay with that. If > you agree, please CC the list on the next reply. If not, let me know. > > > > I'm somewhat partial to having SetStorageLocation and > GetStorageLocation either take three arguments to mimic the > CPMS command, or just set the location of the received > messages and allow the List,Get (etc) commands to call CPMS > (if necessary) on each invocation. > > > > -Jason > > > > > > On Mon, Mar 21, 2011 at 9:55 AM, Eric Shienbrood > mailto:e...@google.com>> wrote: > > Hi Torgny, > > > > I don't think one would typically want to change the > storage location on a call-by-call basis. So it probably > makes the most sense to have a separate call as you suggest > for setting the type of memory to be used. Maybe we could > pick a name like SetStorageLocation. It could set the storage > to be used for Get, Save, List, and SendFromStorage methods. > I think we should also have a GetStorageLocation method. > > > > Also, the spec says that a "Completed" signal is supposed > to be send when all parts of a message have been received. > From the description, it sounds like SmsReceived is supposed > to be sent when the first part is received, Completed is > supposed to be sent when the last part is received, and no > signals are sent for any parts between the first and the last. > > > > Eric > > > > On Sun, Mar 20, 2011 at 1:20 PM, Torgny Johansson > mailto:torgny.johansson@ericsso > n.com>> wrote: > &g
Re: SV: Ericsson Support for SMS receive
On Wed, 2011-03-23 at 12:07 +0100, Marcel Holtmann wrote: > Hi Torgny, > > > > > CCing NetworkManager mailing list. I'm sorry that the thread below is > > > > not > > > > formatted the way you like it but I'm keeping it below for reference. > > > > > > > > The discussion is about sms support in ModemManager. I've started > > > > implementing it a bit but ran into issues. > > > > > > > > I think that a SetStorageLocation method as suggested by Eric would be > > > > sane to add. And have that mirror the CPMS command as Jason suggested. > > > > > > > > Should I still include the mem-type in SmsReceived signal? Or should we > > > > assume that the caller takes care of setting the storage correctly? The > > > > same question is valid for the SmsGet method (and delete). > > > > > > > > About the SmsReceived vs Completed signals, I interpreted it as the > > > > SmsReceived signal is emitted for all sms and for the final sms _both_ > > > > the SmsReceived and Completed signals are emitted. I don't have the code > > > > available right now though, so I'll have to look at it again later. > > > > > > > > Another issue is how to handle the completed flag in the SmsReceived > > > > signal and the Completed signals. I suppose one have to parse the pdu to > > > > be able to tell? > > > > > > using the SIM card as storage for SMS is a pretty much bad idea. It will > > > work sort of nice at first, but in the long run it will give you a lot > > > of problems. It is limited in storage space and vulnerable to denial of > > > service attacks with multipart SMS. > > > > So do you suggest defaulting to ME without even offering the option to the > > caller? In that case, I guess having the memory type in the SmsReceived > > signal > > is kind of redundant... > > if you are serious with SMS support effort, then that is what I would > propose. SIM storage has never been a good idea in the first place. > > > > Another problem is trying to make text mode for SMS on an AT modem work. > > > That will fail since every single modem makes a mistake with text mode > > > handling. Once you enter the cases with non-English character sets, you > > > will be fighting wind mills. You need to use PDU mode. > > > > Agreed, and we don't even have the option to use text mode with Ericsson > > modems. Only pdus are supported. But as the dbus interface is specified > > now, we > > need to parse the pdu in ModemManager. Or do you mean that that should be > > left > > to the caller as well? > > You need to handle all PDU related efforts inside ModemManager. Giving > this kind of detail to the caller is going fail. Handling the PDUs > correctly is actually highly complicated. > > Once you enter the area of concatenated and binary SMS this all becomes > pretty much tricky. You need a damn good handling on this. I tend to agree, I think sending this stuff up to callers isn't the right approach. There's enough detail to handle that we probably do need to handle it and provide the abstraction in MM. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
On Mon, 2011-03-21 at 17:20 +0100, Torgny Johansson wrote: > Hi! > > CCing NetworkManager mailing list. I'm sorry that the thread below is not > formatted the way you like it but I'm keeping it below for reference. > > The discussion is about sms support in ModemManager. I've started > implementing it a bit but ran into issues. Excellent! > I think that a SetStorageLocation method as suggested by Eric would be sane > to add. And have that mirror the CPMS command as Jason suggested. Sure, that sounds fine, unless we decide to just ignore SIM storage completely and use local storage like Marcel suggests. > Should I still include the mem-type in SmsReceived signal? Or should we > assume that the caller takes care of setting the storage correctly? The same > question is valid for the SmsGet method (and delete). I guess it depends on the decision above... > About the SmsReceived vs Completed signals, I interpreted it as the > SmsReceived signal is emitted for all sms and for the final sms _both_ the > SmsReceived and Completed signals are emitted. I don't have the code > available right now though, so I'll have to look at it again later. 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. > Another issue is how to handle the completed flag in the SmsReceived signal > and the Completed signals. I suppose one have to parse the pdu to be able to > tell? Yeah, likely. There's a bunch of charset handling code in MM already, I did the GSM charset work last year (minus the special codepage handling via escapes) so we can extend that. But PDU mode needs to be implemented. Dan > Regards > Torgny > > > Från: Jason Glasgow [jglas...@google.com] > Skickat: den 21 mars 2011 15:32 > Till: Eric Shienbrood > Kopia: Torgny Johansson; Jonas Sjöquist; Malin Gustafsson; Trond Wuellner; > Nathan Williams > Ämne: Re: Ericsson Support for SMS receive > > Hi Torgny, > > I'd like to move this discussion to the nm list, but before I do so I want to > make sure that you are okay with that. If you agree, please CC the list on > the next reply. If not, let me know. > > I'm somewhat partial to having SetStorageLocation and GetStorageLocation > either take three arguments to mimic the CPMS command, or just set the > location of the received messages and allow the List,Get (etc) commands to > call CPMS (if necessary) on each invocation. > > -Jason > > > On Mon, Mar 21, 2011 at 9:55 AM, Eric Shienbrood > mailto:e...@google.com>> wrote: > Hi Torgny, > > I don't think one would typically want to change the storage location on a > call-by-call basis. So it probably makes the most sense to have a separate > call as you suggest for setting the type of memory to be used. Maybe we could > pick a name like SetStorageLocation. It could set the storage to be used for > Get, Save, List, and SendFromStorage methods. I think we should also have a > GetStorageLocation method. > > Also, the spec says that a "Completed" signal is supposed to be send when all > parts of a message have been received. From the description, it sounds like > SmsReceived is supposed to be sent when the first part is received, Completed > is supposed to be sent when the last part is received, and no signals are > sent for any parts between the first and the last. > > Eric > > On Sun, Mar 20, 2011 at 1:20 PM, Torgny Johansson > mailto:torgny.johans...@ericsson.com>> wrote: > Hi! > > I started writing a more proper implementation but ran into some questions... > > I extended the SmsReceived signal to also include the memory where the sms is > stored (but not the actual sms). Then I started implemeting the GetSms method > (also extending it to include the memory type as an argument). The issue I > ran into is that the at command to read messages doesn't use the memory type, > only the index. The memory type should be set with the CPMS command. So > should the GetSms method set that every time or should we instead add a > SetMemory method to do that and remove the memory type from the GetSms method > again? > > Please let me know what you think. > > Thanks! > > Regards > Torgny > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
Hi Torgny, > > > CCing NetworkManager mailing list. I'm sorry that the thread below is not > > > formatted the way you like it but I'm keeping it below for reference. > > > > > > The discussion is about sms support in ModemManager. I've started > > > implementing it a bit but ran into issues. > > > > > > I think that a SetStorageLocation method as suggested by Eric would be > > > sane to add. And have that mirror the CPMS command as Jason suggested. > > > > > > Should I still include the mem-type in SmsReceived signal? Or should we > > > assume that the caller takes care of setting the storage correctly? The > > > same question is valid for the SmsGet method (and delete). > > > > > > About the SmsReceived vs Completed signals, I interpreted it as the > > > SmsReceived signal is emitted for all sms and for the final sms _both_ > > > the SmsReceived and Completed signals are emitted. I don't have the code > > > available right now though, so I'll have to look at it again later. > > > > > > Another issue is how to handle the completed flag in the SmsReceived > > > signal and the Completed signals. I suppose one have to parse the pdu to > > > be able to tell? > > > > using the SIM card as storage for SMS is a pretty much bad idea. It will > > work sort of nice at first, but in the long run it will give you a lot > > of problems. It is limited in storage space and vulnerable to denial of > > service attacks with multipart SMS. > > So do you suggest defaulting to ME without even offering the option to the > caller? In that case, I guess having the memory type in the SmsReceived > signal > is kind of redundant... if you are serious with SMS support effort, then that is what I would propose. SIM storage has never been a good idea in the first place. > > Another problem is trying to make text mode for SMS on an AT modem work. > > That will fail since every single modem makes a mistake with text mode > > handling. Once you enter the cases with non-English character sets, you > > will be fighting wind mills. You need to use PDU mode. > > Agreed, and we don't even have the option to use text mode with Ericsson > modems. Only pdus are supported. But as the dbus interface is specified now, > we > need to parse the pdu in ModemManager. Or do you mean that that should be > left > to the caller as well? You need to handle all PDU related efforts inside ModemManager. Giving this kind of detail to the caller is going fail. Handling the PDUs correctly is actually highly complicated. Once you enter the area of concatenated and binary SMS this all becomes pretty much tricky. You need a damn good handling on this. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
Hi Marcel, måndagen den 21 mars 2011 17.57.30 skrev Marcel Holtmann: > Hi Torgny, > > > CCing NetworkManager mailing list. I'm sorry that the thread below is not > > formatted the way you like it but I'm keeping it below for reference. > > > > The discussion is about sms support in ModemManager. I've started > > implementing it a bit but ran into issues. > > > > I think that a SetStorageLocation method as suggested by Eric would be > > sane to add. And have that mirror the CPMS command as Jason suggested. > > > > Should I still include the mem-type in SmsReceived signal? Or should we > > assume that the caller takes care of setting the storage correctly? The > > same question is valid for the SmsGet method (and delete). > > > > About the SmsReceived vs Completed signals, I interpreted it as the > > SmsReceived signal is emitted for all sms and for the final sms _both_ > > the SmsReceived and Completed signals are emitted. I don't have the code > > available right now though, so I'll have to look at it again later. > > > > Another issue is how to handle the completed flag in the SmsReceived > > signal and the Completed signals. I suppose one have to parse the pdu to > > be able to tell? > > using the SIM card as storage for SMS is a pretty much bad idea. It will > work sort of nice at first, but in the long run it will give you a lot > of problems. It is limited in storage space and vulnerable to denial of > service attacks with multipart SMS. So do you suggest defaulting to ME without even offering the option to the caller? In that case, I guess having the memory type in the SmsReceived signal is kind of redundant... > > Another problem is trying to make text mode for SMS on an AT modem work. > That will fail since every single modem makes a mistake with text mode > handling. Once you enter the cases with non-English character sets, you > will be fighting wind mills. You need to use PDU mode. Agreed, and we don't even have the option to use text mode with Ericsson modems. Only pdus are supported. But as the dbus interface is specified now, we need to parse the pdu in ModemManager. Or do you mean that that should be left to the caller as well? Regards Torgny ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SV: Ericsson Support for SMS receive
Hi Torgny, > CCing NetworkManager mailing list. I'm sorry that the thread below is not > formatted the way you like it but I'm keeping it below for reference. > > The discussion is about sms support in ModemManager. I've started > implementing it a bit but ran into issues. > > I think that a SetStorageLocation method as suggested by Eric would be sane > to add. And have that mirror the CPMS command as Jason suggested. > > Should I still include the mem-type in SmsReceived signal? Or should we > assume that the caller takes care of setting the storage correctly? The same > question is valid for the SmsGet method (and delete). > > About the SmsReceived vs Completed signals, I interpreted it as the > SmsReceived signal is emitted for all sms and for the final sms _both_ the > SmsReceived and Completed signals are emitted. I don't have the code > available right now though, so I'll have to look at it again later. > > Another issue is how to handle the completed flag in the SmsReceived signal > and the Completed signals. I suppose one have to parse the pdu to be able to > tell? using the SIM card as storage for SMS is a pretty much bad idea. It will work sort of nice at first, but in the long run it will give you a lot of problems. It is limited in storage space and vulnerable to denial of service attacks with multipart SMS. Another problem is trying to make text mode for SMS on an AT modem work. That will fail since every single modem makes a mistake with text mode handling. Once you enter the cases with non-English character sets, you will be fighting wind mills. You need to use PDU mode. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
SV: Ericsson Support for SMS receive
Hi! CCing NetworkManager mailing list. I'm sorry that the thread below is not formatted the way you like it but I'm keeping it below for reference. The discussion is about sms support in ModemManager. I've started implementing it a bit but ran into issues. I think that a SetStorageLocation method as suggested by Eric would be sane to add. And have that mirror the CPMS command as Jason suggested. Should I still include the mem-type in SmsReceived signal? Or should we assume that the caller takes care of setting the storage correctly? The same question is valid for the SmsGet method (and delete). About the SmsReceived vs Completed signals, I interpreted it as the SmsReceived signal is emitted for all sms and for the final sms _both_ the SmsReceived and Completed signals are emitted. I don't have the code available right now though, so I'll have to look at it again later. Another issue is how to handle the completed flag in the SmsReceived signal and the Completed signals. I suppose one have to parse the pdu to be able to tell? Regards Torgny Från: Jason Glasgow [jglas...@google.com] Skickat: den 21 mars 2011 15:32 Till: Eric Shienbrood Kopia: Torgny Johansson; Jonas Sjöquist; Malin Gustafsson; Trond Wuellner; Nathan Williams Ämne: Re: Ericsson Support for SMS receive Hi Torgny, I'd like to move this discussion to the nm list, but before I do so I want to make sure that you are okay with that. If you agree, please CC the list on the next reply. If not, let me know. I'm somewhat partial to having SetStorageLocation and GetStorageLocation either take three arguments to mimic the CPMS command, or just set the location of the received messages and allow the List,Get (etc) commands to call CPMS (if necessary) on each invocation. -Jason On Mon, Mar 21, 2011 at 9:55 AM, Eric Shienbrood mailto:e...@google.com>> wrote: Hi Torgny, I don't think one would typically want to change the storage location on a call-by-call basis. So it probably makes the most sense to have a separate call as you suggest for setting the type of memory to be used. Maybe we could pick a name like SetStorageLocation. It could set the storage to be used for Get, Save, List, and SendFromStorage methods. I think we should also have a GetStorageLocation method. Also, the spec says that a "Completed" signal is supposed to be send when all parts of a message have been received. From the description, it sounds like SmsReceived is supposed to be sent when the first part is received, Completed is supposed to be sent when the last part is received, and no signals are sent for any parts between the first and the last. Eric On Sun, Mar 20, 2011 at 1:20 PM, Torgny Johansson mailto:torgny.johans...@ericsson.com>> wrote: Hi! I started writing a more proper implementation but ran into some questions... I extended the SmsReceived signal to also include the memory where the sms is stored (but not the actual sms). Then I started implemeting the GetSms method (also extending it to include the memory type as an argument). The issue I ran into is that the at command to read messages doesn't use the memory type, only the index. The memory type should be set with the CPMS command. So should the GetSms method set that every time or should we instead add a SetMemory method to do that and remove the memory type from the GetSms method again? Please let me know what you think. Thanks! Regards Torgny ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
