org.freesmartphone.GSM.SMS

[Bernhard Kaindl]

On Fri, 16 May 2008, Vesa Pikki wrote:
>> 
>> I'm currently integrating gsmd2 to an sms application, but I'm having
>> trouble with current api. The application has 3 tabs called Inbox,
>> Outbox and Sent. I'd like to be able to retrieve messages to these three
>> categories. Also the application should be able to display if a message
>> has been read or not and have the ability to set a message read.

This is functionality is more high-level than what a simple gsmd which
Mickey described in his answer to my also very high-level API proposal
could provide. I'll talk about it below. First I quote from Mickey's
answer to my high-level API example:

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

The API which Mickey describes would be very tailored to the SIM, and
just support what a SIM supports.

Looking at some new phones (speaking of e.g. Nokia E51 here), they have
their internal advanced SMS handling with folders/status as you describe
(Inbox, Outbox, Sent, Drafts, Reports, and user-defined folders), but
such advanced information cannot be stored on a SIM using the straight
07.07/07.05 API. But I think I saw also sometimes some way to get to
the SIM and access what is stored on the SIM, which is different from
what is stored in the Phone's memory.

>> I'm thinking that we should first define SMS message as fso API sees it.
>> Here is a very simplified example of SMS's variables to get us going.
>> Feel free to modify/rename/add/remove fields as you see fit.
>> 
>> SMS:
>> - string message, contents of the message
>> - string number, sender's or receiver's phone number
>> - int timestamp, time the message was received/sent

So far, this could be supported by a simple gsmd using only 07.07/07.05.

>> - string status, message's status: received, sending, sent, draft

I would have to study the 07.07/07.05 more but I think this (sending,
sent, draft) is slightly beyond of what I could provide based only
using SIM information thru 07.07/07.05.

>> - string direction, was message sent or received: received, sent

07.07/07.05 has two separate "folders", one for Incoming and one for
Outgoing messages, "direction" could be mapped to that, but "sent"
would have to be mapped to "outgoing" as a message which is going
to be sent would e.g. be written to the outgoing message area first
like a 'draft'.

>> - boolean read, has the message been read (could also be used with
>> SendMessage's want_report parameter)

The SIM does provide a "boolean read" flag, but it's unset by the
SIM or GSM modem itself when the message is retrieved thru 07.07/07.05,
independent of if a use did actually read the SMS, I cannot set this
flag, I can only select SMS based if it has already been retrieve
from the SIM or not if I wish to do this selection. (as far as I
remember).

>> Lastly I'd like to add a method to update message's read variable.
>> Either just
>> <method name="SetMessageRead">
>>     <annotation name="org.freedesktop.DBus.GLib.Async" 
>> value="fso_gsm_sms"/>
>>     <arg type="i" name="index" direction="in"/>
>>     <arg type="b" name="read" direction="in"/>
>> </method>
>> 
>> or if RetrieveMessage uses "a{sv}", then with
>> <method name="SetMessageProperty">
>>     <annotation name="org.freedesktop.DBus.GLib.Async" 
>> value="fso_gsm_sms"/>
>>     <arg type="i" name="index" direction="in"/>
>>     <arg type="s" name="key" direction="in"/>
>>     <arg type="v" name="value" direction="in"/>
>> </method>

Basically, to support these methods and in general your applications's
view of SMS in a data storage, the API would have to be implemented
using a separate high-level SMS daemon which would operate on its own
data storage and do the low-level operations like actual send and
receive of SMS and SIM card data access thru a low-level SMS API.

The low-level SMS api could (to indicate this) be somehow located
new the GSM or even SIM level (even if it needs the network to send
and receive SMS) while the high-level API would be free of the
limiations of the low-level SIM/GSM api and provide such high-level
features like custom and even hierachical SMS folders to applications.

But that would be a separate daemon which just needs a low-level API
to the SIM and GSM and otherwise operate using it's own data storage
e.g. needed to implement this:

> I'm leaning towards replacing status variable with folder (string) variable 
> and have inbox,outbox and sent as default values as far as gsmd2 knows. This 
> would allow more flexibility and the ability to have subfolders. Also I'd 
...

> As I've understood, sending an SMS would involve storing a message with 
> StoreMessage then calling SendMessage. Would it be the job of a gsm daemon to 
> move that sms from draft folder to outbox and finally to sent folder? When 
> gsm daemon fails to send an sms, how and when should it be retried?

That would be to befined and implemented in the high-level SMS daemon.
The low-level SIM-only SMS interface provides for sending but not for
tracking status of retrying the sending of an SMS for example.

> Automatically after n minutes or manually? And how should we separate message 
> sending confirmations from actual messages with some field for example?

The Nokia E51 has a separate folder "Reports" for this which does make
sense to me, old Nokia phones just did put them into the Inbox which
filled up the Inbox with rather uninteresting mails, so I think it's
an improvement.

As far as I remember from reading the specs, the GSM can ask for such
message sending confirmations but they are received in some way like
an 'ACK' with a reference to a SMS which has been sent and are special.

These confirmation didn't look like ordinary SMS to me so in a
high-level API one could even image that they could end up just
as a status flag which gets added to SMS which were sent with
SMS sending confirmation on.

I think there is even a "SMS read" confirmation which can be sent by the
receiving GSM when the receiving GSM device has received the SMS and it
had been "read" by it's own SMS daemon. (but that's rather advanced)

Bernhard.