Questions, notes and comments

[Michael 'Mickey' Lauer]

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?

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

Yep.

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

Fully Agreed. This is a sane way. Emdete, you will probably like that as
well, right? We have a high-level interface and a low-level then, sanely
grouped into SIM and Storage. I'm in Austria this week -- I'm going to
move the respective methods from SMS and Phonebook into SIM when I'm
back in Germany.

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

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

Ok, good.

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

Emdete, what's your opinion? Stuff it into Device or leave it in MUX?

:M: