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

[Dan Williams <dcbw redhat com>]

On Wed, 2008-08-27 at 17:17 +0200, Pablo Martí wrote:
> On Wed, Aug 27, 2008 at 4:35 PM, Tambet Ingo <tambet gmail com> wrote:
> >
> > I reordered the interfaces a bit:
> >
> >> org.freedesktop.ModemManager.Modem.Gsm.Card: SIM/Card related operations
> >>  - DisableEcho() ->
> >>  - EnableEcho() ->
> >
> > These do not do anything useful from the API user's perspective and
> > shouldn't be included in the public API.
> 
> Agreed
> 
> >
> >>  - Enable(b enable) ->  (This is the Enable method of ModemManager, I
> >> think it goes here but I might be completely wrong here :)
> >
> > Yes. Enable() means initialize the card and check if any secrets are
> > needed (PIN/PUK).
> 
> It seems that Enable will raise an exception indicating whats needed,
> we'll need to agree on the exceptions name... :)
> 
> >
> >>  - GetCharset -> s
> >>  - GetCharsets() -> as
> >>  - SetCharset(s charset) ->
> >
> > Do we need these? Do the modems support UTF8? If they do, let's just
> > default to that. The reason I don't like there much is that they seem
> > a bit too low level.
> 
> I agree that they dont need to be included in the public API as
> they're not that useful for MM, but at the same time if we reach
> consensus here, this API might be the de-facto standard for [W]CDMA on
> Linux (and perhaps other nix*). And our Asian friends _do_ care about
> unicode. This parameter affects responses of commands like (+COPS,
> GetSMSC, SetSMSC, AddContact, FindContact, etc.) The idea is to be in
> UCS2 as much as possible so everyone is happy, and using IRA,GSM as a
> fallback.
> 
> >
> >>  - GetIMEI() -> s
> >>  - GetIMSI() -> s
> >>  - GetManufacturer() -> s
> >>  - GetModel() -> s
> >>  - GetVersion() -> s  (Firmware version)
> >
> > All good ones.
> 
> >
> >> org.freedesktop.ModemManager.Modem.Gsm.Network:
> >>  - GetRegistrationStatus() -> (uu)    (AT+CREG?)
> >>  - GetInfo() -> (su)  (AT+COPS?)
> >>  - GetNames() -> a(ussuu)   (AT+COPS=?)
> >>  - GetRoamingIDs() -> as    (AT+CPOL?)
> >>  - GetSignalQuality() -> u
> >>  - SetRegistrationNotification(b enable) ->
> >>  - SetInfoFormat(u mode, u format) -> (i.e. AT+COPS=3,0)
> >>  - RegisterWithNetID(s netid) ->
> >>
> >>  - CregReceived(u status) ->   (signal)
> >>  - SignalQuality(u rssi) ->   (signal)
> >
> > I think these are too low level. I'd much prefer the current ones from
> > ModemManager.
> 
> You mean:
>  - Register("") -> Tries to register with your home network
>  - Register("24301") -> Tries to register with the given MNC
> 
> 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.

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.

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.

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