Questions, notes and comments

[Vesa Pikki]

Michael 'Mickey' Lauer wrote:
> Am Montag, den 31.03.2008, 08:37 +0300 schrieb Vesa Pikki:
>   
>>>> General notes:
>>>> Timeout and other error replies to method calls should be specified.
>>>>
>>>>         
>>> Why do async. calls need to have a timeout?
>>>
>>>       
>> I was referring to handling timeouts on replies to AT commands sent to
>> gsm modem and specifying an error code for those occasions.
>> For example when making a phone call (sending ATD command) if the gsm
>> modem never replied anything what should be the course of action for gsm
>> daemons? They could send a reply for Initiate method and a Error status
>> signal after that but not all methods in the API have convenient
>> signals. This is why I think a timeout error should be specified.
>>     
>
> Fully agreed -- I did not have this in mind. We will probably need at
> least org.freesmartphone.GSM.Error.
> * Timeout
> * SimRequired
> * PermissionDenied
>
> What else?
>
>   
I would add PinRequired and GeneralError (feel free to rename them better).

Also something relating this is puzzling me. As an example 
org.freesmartphone.SIM interface has SendAuthCode method. When sending 
"AT+CPIN=..." if modem would reply an error, how would that be handled? 
Should the dbus method return normally or should it return an error? How 
about when trying to send a pin code when one is not needed (gsm modem 
returns an error)?

With GetAuthCode, if modem would reply an unspecified error to 
"AT+CPIN?" what should be returned? or should AuthStatus signal be sent 
as to notify about the error? One possible way to deal with these errors 
is to have a return value in each method, but I don't think it's a good 
idea. Similar case is with org.freesmartphone.Call's Initiate and 
release methods.

Also could you define status parameters values to SIM and Call 
interface's methods?
> This is a bit out of topic, but it relates to the API. I'm not sure
>> about the storage implementation, four options come to mind:
>> - Having a separate application as the storage and implementing library
>> for gsm daemon to access the storage. Gsm daemon would implement dbus api.
>> - Having a separate application as storage and imlement dbus storage api
>> aswell.  Gsm daemon could access it through a library and/or dbus.
>> - Having storage implementation behind a library/interface that gsm
>> daemon can call. Gsm daemon would implement storage api in dbus.
>> - Implement everything in gsm daemon.
>>
>> What are your thoughts on this?
>>     
>
> I'm leaning towards a seperate storage daemon. The gsm daemon should
> implement the low level API (SIM), but the storage daemon should
> implement the high level API. As a matter of fact, we have an
> interesting GSoC 2008 proposal for such a PIM/Storage daemon.
>
>   
That sounds good.


-- 
Vesa Pikki