Re: [ANNOUNCE] ModemManager (for GSM and CDMA)



On Wed, Aug 27, 2008 at 6:02 PM, Dan Williams <dcbw redhat com> wrote:
>>
>> I can agree in this two. "AT+COPS?" is a pretty useful command that
>> you've (inadvertently) banned here :), ditto with "At+COPS=?" and
>> "AT+CPOL?" when you have a buggy firmware/old SIM that does strange
>> things while roaming...
>
> COPS? seems like something we could make use of even when disconnected,
> but GetInfo() isn't a very descriptive name.  It just returns the
> currently registered network, which is something that the applet might
> like to make use in the UI.  However, it's unclear how you'd figure out
> when this changed unless you polled, right?  So it might be something
> that the service should keep track of internally and then send out dbus
> signals when the associated operator changes.  That way every app that
> might want to know about operator changes wouldn't need to poll the card
> itself.

Alright, the value could be cached every 60s and we could fire a
signal whenever it changes.

>
> CPOL sounds interesting; could you explain more?  It might be useful to
> get a list of operators that are "preferred" to roam on when setting up
> the card, but I'm not sure.

at+cpol?
+CPOL: 1,2,"23415"
+CPOL: 2,2,"22210"
+CPOL: 3,2,"50503"
+CPOL: 4,2,"20810"
+CPOL: 5,2,"23003"
...

Yeah At+CPOL returns the list of MNCs your provider has agreements
with, most of the cards should use this info internally and you dont
need to mess with this list. Other cards cannot handle it and you
basically issue an "+COPS=?" and check that one of the operators
around are available in the +CPOL? list. Anyway this can be hidden
behind the Register(s netid) command that Tambet proposed.

>
> When in doubt, if there's a not a clear need for the command _right
> now_, it's best to leave it out.  You can always add API; but changing
> and removing it is really hard once people start using your stuff.

True that

Regards,

>
> Dan
>
>> >
>> >> org.freedesktop.ModemManager.Modem.Gsm.PIN:
>> >>  - Change(s oldpin, s newpin) ->
>> >>  - Check() -> u  (Returns the SIM auth state, to check it against an enum)
>> >>  - Enable(s pin) ->
>> >>  - Disable(s pin) ->
>> >>  - Send(s pin) ->
>> >>  - SendPUK(s puk, s pin) ->
>> >
>> > Not sure about these. Currently, Check() is part of
>> > Gsm.Card.Enable(True). Enable(pin)/Disable(pin) could be one method
>> > with a boolean argument. What's the difference (code wise) between
>> > Send() and SendPUK()? So that would leave us with 3 methods:
>> > Enable(bool), Send(string), Change(string, string). If so, maybe they
>> > can be part of the Gsm.Card interface?
>>
>> Enable(b) sounds good to me. The difference between Send and SendPUK
>> is that the former receives just one parameter (the pin), while the
>> later receives two, the puk and the new PIN to set in the card. One of
>> the advantages of having a separate interface is that CDMA devices
>> cant just skip the .PIN interface. Otherwise they'll support half of
>> .Card.
>> >
>> >
>> > For the following methods I don't have strong preferences because I've
>> > never used any of these features and thus don't have any hands on
>> > experience. I'd really appreciate if other interested parties
>> > (Telefonica?) could comment these.
>>
>> Yeah! Roberto?
>>
>> Best regards,
>>
>> >
>> >> org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related operations:
>> >>  - Add(s name, s number) -> u
>> >>  - Delete(u index) ->
>> >>  - Find(s pattern) -> a(uss)
>> >>  - Get(u index) -> (uss)
>> >>  - GetPhonebookSize() -> u    (Could be renamed to GetSize() ?)
>> >>  - List() -> a(uss)
>> >
>> > Looks good to me.
>> >
>> >> org.freedesktop.ModemManager.Modem.Gsm.SMS: SMS related operations:
>> >>  - Delete(u index) ->
>> >>  - Get(u index) -> (ussd)        (The last double is the time when it
>> >> was received)
>> >>  - GetFormat() -> u   (AT+CPBF?)
>> >>  - GetSMSC() -> s
>> >>  - List() -> a(ussd)
>> >>  - Save(s text, s number) -> u
>> >>  - Send -> u
>> >>  - SendFromStorage(u index)
>> >>  - SetFormat(u format) ->
>> >>  - SetIndication(u mode, u mt, u bm, u ds, u bfr) ->   (AT+CNMI=mode,mt,..)
>> >>  - SetSMSC(s smsc) ->
>> >>
>> >>  - SMSReceived(u index, s where)    (signal)
>> >>
>> >> This is just food for thought, what think about such an API the
>> >> different parties involved?
>> >> I've tried to clarify in parentheses all the methods that might be
>> >> misleading or might be controversial, with either its purpose or the
>> >> correspondent AT command. I think that standard interfaces such as
>> >> {SMS, Contacts}.{Delete, List, Get} should definitely go in. Other
>> >> methods (specially its naming) are somewhat more controversial and
>> >> I'll be happy to discuss 'em.
>> >>
>> >> I've attached this interfaces to the Gsm (WCDMA) part, we still need
>> >> to decide what to do with CDMA... Dan? :)
>> >
>> > Tambet
>> >
>>
>>
>>
>
>



-- 
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]