Questions, notes and comments

[Michael 'Mickey' Lauer]

Hi,

> General notes:
> Timeout and other error replies to method calls should be specified.

Why do async. calls need to have a timeout?

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?

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

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

:M:
org.freesmartphone.GSM.Device

-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de