org.freesmartphone.GSM.SIM

[Michael 'Mickey' Lauer]

Hi Bernhard,

On Saturday 19 April 2008 17:53:14 Bernhard Kaindl wrote:
> To have working SendMessage, MessageSent, IncomingMessage you need a
> SIM, but in addition, you need to be registered to a network and be
> connected to it. So they have the same requirements as making and
> receiving calls.

Agreed. We will leave it out from SIM and only put it in SMS.

> This latter mode may be useful when you do not want to be constrained
> by the SIM storage which the GSM modem supports but store SMS in your
> own storage space.

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

With that in mind, read the following comments:

> I mentioned "SMS storage" a couple of times here. Such SMS storage does
> not need to be the SIM card itself, Most newer GSM phones can write SMS
> directly to some other internal storage space, outside of the SIM.
>
> The old Nokia 6150 probably only writes SMS to SIM but some newer ones
> like the Sony T610 certainly seems to write SMS to some internal SMS
> storage. In fact, the GSM 07.05 technical specification provides for
> some standed message storages names:
>
> "BM" broadcast message storage
> "ME" ME message storage
> "MT" any of the storages associated with ME
> "SM" SIM message storage
> "TA" TA message storage
> "SR" status report storage
>
> The GSM modem in my GTA01v4 uses "SM" (the SIM card) by default and
> seems to also have "ME" ("Mobile Equipment"), but the ME storage does
> not seem to work right, maybe because the GSM modem in my GTA01v4 is
> really just configured as a modem an not as a full-blown phone like
> the GSM part of normal feature-phones like the Sony T610 would be.

We don't really need all that fancy stuff. We are not a feature phone, however 
we need to support contacts and messages on SIM cards, because our users will 
expect that they can use the stuff that's stored on the SIM. This basically 
means in org.freesmartphone.GSM.SIM we really only need to provide low level 
storage abstraction to read and write ontacts and messages from the SIM and 
we're done.

> So depending on whether the freesmartphone API should also support
> some more powerful GSM devices like fully features phones and
> smartphones which have other SMS storage means besides the SIM
> which is often very limited in space (I think mine can fit maybe
> 20 or 32 received SMS), I would not neccesarily associate SMS with
> the SIM at all.
>
> The same applis to the phonebook storage. Fully-featured GSM devices
> (exluding the GSM modem of my Neo here) Phonebook entries can store
> phonebook entries outside of the SIM which is also very limited in
> space and information richness. Other phnonebook storage besides SIM
> are supported by the tools which I looked at (gammu/gnokki or gsmlib)
>
> Similar to other phones, also "free" phones like the OpenMoko or other
> devices coming up could also support and use such SIM-external SMS
> and phonebook storage and it may be useful to be able to use the
> freesmartphone API also for access to such information in such storage
> from outside of the phone itself, say when I connected an OpenMoko
> phone (running whatever software) to my Computer and be able to
> access phonebook entries and SMS on the phone using the API.
>
> To address the storage space to use, the DBUS object_path could be
> useful. E.g. to address the SIM storage, an object_path ending with
> /SIM could be used while e.g. /Device could be used to access storage
> of the device itself.
>
> That's not an idea of mine, I got that idea Michael when he proposed
> to me to use the Storage API method for both SMS and phonebook.

Which is a great idea, but it should not be the only means to access the data.

> The only difference besides the object path would be the acutal data
> which is saved and retrieved.
>
> The data actual data which can be saved and retrieved would be dependent
> on the object path and be rather fixed for SIM-stored SMS and phonebook,
> while it could be very detailed for SIM-external phonebooks for example.
>
> My suggestion for SendMessage, MessageSent, IncomingMessage would be
> to place it at a location where it's clear that they will only work
> when the phone is in an on-line status, connected to the network,
> even inside of a new path like org.freesmartphone.GSM.Network.Online
> to make that clear.
>
> Accessing SMS and phonebook information in the SIM only works if the
> SIM authentication status is "READY", which may require the SIM to
> be authenticated with a PIN.
>
> It appears to me that also access to other private information like
> SIM-external SMS and phonebook entries should (optionally) require
> authentication to the device by means of a PIN for example.
>
> I don't know of your thoughs for this, but some phones have (besides the
> SIM's PIN) some other locking codes which can optionally be enabled.
> Maybe such provisions may be useful also for accessing private
> device-local information like SIM-external SMS and phone book
> information.
>
> Any such authentication may be shared for SMS and phonebook storage
> and a default may be to check for the SIM authentication status and
> use that also for off-SIM information, or the device could use another
> authentication API.
>
> I guess that the SIM and phonebook API might provide a method call
> which tells which kind of authentication to use to access SIM and
> phonebook informaiton and a simple answer would be to return e.g.
> "SIM PIN" in that case, which would refer the user of the API to
> use SIM authentication before acessing SMS and phonebook data.
>
> With an example API which uses an object path to specify the storage
> addressed and uses an generic storage API to access SMS info, a
> method call could look like this:
>
> object_path=/org/mobile/GsmPhone/SMS/SIM
> org.freesmartphone.GSM.Storage.GetAuthMethod() could return: "SIM PIN"
>
> It could be specified to always return a list of strings (string array)
> to have the API supporting cases where multible autentication methods
> may be asked by the device.
>
> Other object paths would be e.g.:
>
> /org/mobile/GsmPhone/SMS/SIM
> /org/mobile/GsmPhone/SMS/Device
> /org/mobile/GsmPhone/Phonebook/SIM
> /org/mobile/GsmPhone/Phonebook/Device
>
> To support multible phones connected to one Computer, the API may
> possibly be extended to provide for a method to Enumerate and List
> the GSM phones connected to a computer and then do all access to them
> using an Object Path which is returned by the GSM phone enumeration API,
> e.g. a sequence like this could be used:
>
> /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.

:M:
-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de