streamlining the API

[Heikki Paajanen]

Hi Mickey,


2008/5/20 Michael 'Mickey' Lauer <mickey at vanille-media.de>:
> As you might know, I'm currently implementing the fs.o GSM dbus API in
> python-ophoned and I found some warts that I want to fix:
>
> === org.freesmartphone.GSM.Device ===
>
> CHANGESIG: GetInfo() should return a{sv} instead of a fixed set of parameters.
> Some devices might not implement all of (+CGMI,+CGMM,+CGMR,+CGSN) and some
> might have important additional information to add here.
>
> ADD: PrepareToSuspend(). This method is optional, implementers might want to
> use this to temporarily turn off unsolicited messages which may wake up a
> modem from suspend.
>
> ADD: RecoverFromSuspend(). This method is optional, implementers might want to
> use this to turn sending unsolicited messages on again and perhaps check for
> messages that were lost during the wakeup sequence.
>
> === org.freesmartphone.GSM.SIM ===
>
> REMOVE: GetImsi, GetSubscriberNumbers, and GetCountryCode. To combine as
> GetSimInfo.
>
> ADD: GetSimInfo()->a{sv}. Contains information from GetImsi,
> GetSubscriberNumbers, and GetCountryCode. Implementers might chose to add
> specific SIM information here.
>
> ADD: SetEnableAuthCodeCheck(b), GetEnableAuthCodeCheck() -> b. To specify
> whether the SIM is checks the auth code on startup or not (AT+CLCK,"SC",<b>).
>
> ADD: SendSMS(i). Sending an SMS that is stored on the SIM seems to belong to
> the functionality of this interface.
>
> ADD: RetrievePhonebook() -> a(iss). Retrieve the whole phonebook with one
> call. This is what most applications will do on startup once -- and then
> probably handle the phonebook in phone memory on their own.
>
> ADD: RetrieveMessagebook() -> a(iss). Retrieve the whole messagebook with one
> call. This is what most applications will do on startup once -- and then
> probably handle the messagebook in phone memory on their own.
>
> === org.freesmartphone.GSM.Network ===
>
> CHANGESIG: GetStatus() and the corresponding signal should return a{sv} here
> instead of a fixed set of parameters.
>

Agreed.

> === org.freesmartphone.GSM.Call ===
>
> QUESTION: Should CallStatus rathern always return the maximum available
> information or only the change bits? Consider that passing more data in one
> dbus call is relatively cheap, whereas additional roundtrips (like calling
> GetCallStatus() to receive the full status) are expensive. I'm +- 0 here, any
> strong opinions?

I think it's usefull to always return maximum available. That way we
won't force UI applications to cache the status data.

   Hessu