Questions, notes and comments

[Vesa Pikki]

Michael 'Mickey' Lauer wrote:
> Hi,
>
>   
>> 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.
> Yes, we have zero work done for errors yet. We need to do that asap. We should
> let us be inspired by the BlueZ 4 Dbus API which has quite comprehensive
> error specifications.
>
>   
>> org.freesmartphone.GSM.Storage.xml:
>> Most methods have int primary_key, modify entry has string primary_key
>> org.freesmartphone.GSM.SMS uses int index, should they all be string
>> primary_keys?
>>     
>
> Yes. Done in r112. Nearby, this interface will probably move to
> org.freesmartphone.Storage as it's going to be a slightly more highlevel
> approach including certain PIM types.
>
>   
>> org.freesmartphone.GSM.Phonebook.xml:
>> StoreEntry has index with direction "in", should it modified to be like
>> Storage that there are methods StoreEntry and a separate ModifyEntry
>>     
>
> If we are to keep the GSM.Phonebook interface then yes (I added a comment so
> that we don't forget). Thinking more about it though, I want to remove this
> as a seperate interface and add it to the SIM interface instead. There, it
> only deals with SIM phonebook entries. Everything else should be covered by
> the org.freesmartphone.Storage API.
>
>   
>> org.freesmartphone.GSM.SMS.xml:
>> SMS doesn't have any methods to modify a message. For drafts it might be
>> useful.
>>     
>
> Right, however I don't think this needs to be exposed through the actual dbus
> interface. It would be just a convenience method, however I'd like to keep
> the interface as small as possible -- and you can get the same functionality
> with RetrieveMessage and StoreMessage.
>
> As for the actual access to the SMes stored on the SIM, I'm leaning towards
> doing the same as for phonebook and moving this to the SIM interface -- with
> org.freesmartphone.storage interface providing higher level functions. What
> do you think?
>
>   
When implementing gsm daemon I'd rather separate storage from the 
application. Therefore I'd rather have all storage related methods and 
signals in org.freesmartphone.storage since they are read from an 
external storage and since SMS messages in SIM are read using AT 
commands, I'd have them in SIM interface. It should be well documented 
that the preferred place for storing SMS messages would be the storage 
and that SMS api should only be used if necessary.

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?
>> org.freesmartphone.GSM.Call.xml
>> Microphone and/or speaker volume settings (the ones that are done with
>> at-commands AT+CRSL and AT+CLVL) might be added here.
>>     
>
> We can do that, however this is kind of a layering violation in a smartphone
> stack, since on these systems, you typically have mixer controlled by the AP,
> not the BP.
>
> If we want to support feature phones as well, then yes, let's add it. In that
> case we need to document though, that these functions will do nothing on most
> hardware.
>
>   
My thoughts exactly.
>> org.freesmartphone.GSM.Network.xml
>> SubscriberNumbers has string argument, should it be string array instead?
>>     
>
> This is a good question -- it boils down to whether we get notified by the
> network when our subscriber number(s) change. Does anyone know whether this
> is the case and how this actually works at all? In the meantime, I'll add the
> array.
>
>   
>> org.freesmartphone.GSM.Device.xml
>> GetFeatures should propably be of type a{sv}?
>>     
>
> Right, done.
>
>   
>> SetFunction never quite understood the meaning of this.
>>     
>
> Bogus name. I renamed this to setAntennaPower.
>
> Further question... what would you prefer to put the small MUX interface into:
>
> org.freesmartphone.GSM.MUX or rather
> org.freesmartphone.GSM.Device ?
>
> My gut feeling is it would make sense to put it into device as well. (We
> should not have too many different prefixes, only as much as necessary to
> make the subsystems clear to the users of our APIs).
>   
As long as the prefixes don't get stuffed. Currently device api doesn't 
have a lot of useful content so it would be a good place for muxing 
related methods.
> :M:
> org.freesmartphone.GSM.Device
>
> --
> Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de
>
> _______________________________________________
> smartphones-standards mailing list
> smartphones-standards at linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
>   


-- 
Vesa Pikki