org.freesmartphone.GSM.SIM

[Bernhard Kaindl]

Hi Mickey,

On Thu, 24 Apr 2008, Michael 'Mickey' Lauer wrote:
>
> Please try to acknowledge one basic paradigm:
>
> The freesmartphone.org API is to get a reasonable balance between
> * being too low level (read: a straight 07.07/07.05 mapping) and
> * being too high level (read: telepathy, many abstract and generic concepts
> everywhere but hardly supporting the telephony specifics).

Yep, makes sense.

...
>> /org/mobile/GsmPhone/Enumerate:
>> org.freesmartphone.GSM.ListPhones() -> {"FIC_GTA01v4_SN1234556"}
>>
>> /org/mobile/GsmPhone/FIC_GTA01v4_SN1234556/SMS/Device:
>> org.freesmartphone.GSM.Storage.GetAuthMethod() {"SIM PIN"}
>>
>> /org/mobile/GsmPhone/FIC_GTA01v4_SN1234556:
>> org.freesmartphone.GSM.SIM.SendPin("1111")
>> org.freesmartphone.GSM.SIM.AuthStatus() -> "READY"
>>
>> /org/mobile/GsmPhone/FIC_GTA01v4_SN1234556/SMS/Device:
>> org.freesmartphone.GSM.Storage.ListEntries() -> {"1","2","3"}
>> org.freesmartphone.GSM.Storage.RetieveEntry("1") -> ("Number":"+49xxx",
>>       "Text":"Good day!", "Time":"2008/02/03 15:22", .....)
>
> This is all great and cool and thought through, but there's a heavy alarm
> clock titled "bloat" flashing when I read this. I think it's overengineered.
> I would really love to first come up with a
> * small,
> * simple and easy-to-use,
> * procedural API
> that provides enough functionality that bread-and-butter applications need
> from org.freesmartphone.GSM.
>
> With that API done, in a 2nd step we can think about a more generic, abstract
> and OO-oriented API on top of that. Depending on the actual flexibility (and
> complexity), an application can then chose to use the simple procedural or
> the more abstract OO-centric API.

The idea to have a low-level and a high-level API for different needs
makes sense to me, especially in the proposals and questions which
Vesa Pikki sent regarding his work on integrating gsmd2 to an sms
application a week ago. I'll reply to it now.

Bernhard