org.freesmartphone.GSM.SMS

[Vesa Pikki]

Vesa Pikki wrote:
> Hi
>
> 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.
>
> 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
> - string status, message's status: received, sending, sent, draft
> - string direction, was message sent or received: received, sent
> - boolean read, has the message been read (could also be used with
> SendMessage's want_report parameter)
>
> To support these variables I'd like to modify some
> org.freesmartphone.GSM.SMS's methods. Here are some proposals:
>
> <method name="ListMessages">
>     <annotation name="org.freedesktop.DBus.GLib.Async" value="fso_gsm_sms"/>
>     <arg type="s" name="status" direction="in"/>
>     <arg type="ai" name="indices" direction="out"/>
> </method>
>
> Status would have these values:
> received
> sending
> sent
> draft
> all (ignore status and retrieve all messages)
>
> Status could also be replaced with <arg type="s" name="directory"
> direction="in"/>
> which could have values "received", "sending", "sent", "draft", "all".
> With directories we could have inbox with subdirectories such as read
> and unread and so forth.
>
>
> <method name="RetrieveMessage">
>     <annotation name="org.freedesktop.DBus.GLib.Async" value="fso_gsm_sms"/>
>     <arg type="i" name="index" direction="in"/>
>     <arg type="s" name="number" direction="out"/>
>     <arg type="s" name="message" direction="out"/>
>     <arg type="s" name="status" direction="out"/>
>     <arg type="s" name="direction" direction="out"/>
>     <arg type="b" name="read" direction="out"/>
> </method>
>
> Add this method support for all SMS's parameter's. Or put them all
> inside <arg type="a{sv}" name="message" direction="out"/> and define the
> key's.
> similar to parameters above.
>
> 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>
>
> --
> Vesa Pikki
>
>
> _______________________________________________
> smartphones-standards mailing list
> smartphones-standards at linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
>   
Couple more thoughts about this email.
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 prefer <arg type="a{sv}" name="message" 
direction="out"/> in SetMessageProperty (and rename it ModifyMessage) 
and StoreMessage. This way all the methods have a similar signature and 
allow metadata aswell. StoreMessage should have at least message and 
number as required fields, others would be set to default values defined 
in the api.

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? Automatically after n minutes or manually? And how should we 
separate message sending confirmations from actual messages with some 
field for example?

-- 
Vesa Pikki