Hi
> On Friday, Mickey mentioned to me that libmokogsmd would probably not be
> used in the final software stack. Instead, he would prefer a d-bus based
> interface to GSMD.
Great !
> Yesterday, Rob, Chris and I sat down around a
> whiteboard and came up with some thoughts on how the phone functionality
> in GUI applications might be managed.
Great ! Good News...
I have already spend quite some time thinking about how such an
interface might look like.
In my opinion, the best solution is to have a separate DBus-Service
for each independent State machine of the openmoko problem space, and
to implement all these DBus-Services in a single daemon.
Lets call this daemon "openmokod" or just "mokod". It would provide
the openmoko platform abstraction.
This daemon might for example implement a DBUS-Service / Object to
access the SIM Card.
org.openmoko.SIM:
* Goals:
- Abstract the fact that you need to access the SIM via gsmd / libgsmd,
- multiplex SIM Access between different applications (phone book,
SMS, setting, pin dialogs)
- maybe cache some things (phone book ?) in memory
- send a signal that can be hooked in GUI whenever there is a need
to enter a PIN / PUK.
* Possible States: NO_SIM_PRESENT, SIM_OPEN, SIM_LOCKED, NEED_PIN,
NEED_PUK, NEED_PIN2, NEED_PUK2,
* Possible Methodes: enterPIN, enterPUK, enterPIN2, enterPUK2,
changePIN/PUK, close_sim, accessPhonebook, accessSMS, etc...
* Possible Signals: OnNeedPIN, OnNeedPUK, etc...
Advantages of this orthogonal approach: The PIN Problem is dealt with,
whatever reason there is for PIN entry (i.e. reseting the SIM expense
counters from a SIM menu) when the GUI reacts to the
right signal it will show whenever there is a need to enter some PIN / PUK.
Similar Objects could be implemented for:
org.openmoko.GSMNetwork:
* Goal: Abstract all Meta Information about the GSM Network, provide
an interface to choose the network to connect to.
* States: NO_SIGNAL, EMERGENCY-ONLY, REGISTERED_HOME, REGISTERED_VISITOR
* Methodes: getNetworks, setPreferredNetwork, register, unregister,
getDeviationStatus
* Signals: OnSelectNetwork, OnRSSIDChange (to update signal strength
bar), OnAreaCodeChange()
Here we can place some hooks for least cost network selection when on
visitor networks (abroad)
or we can have listeners for the OnAreaCodeChange if they want to do
fancy things like strarting the GPS to update location.
org.openmoko.Ringer:
* Goal: Abstract the possible Mixer Issues, and the loud / meeting profile thing
* States: Profile_X, Profile_Y etc...
* Methods: Ring(callerID) to be called by gsmd , etc...
* Signals: AboutToRing, OnRing...
org.openmoko.VoiceAudioRouting:
* Goal: Abstract the Mixer and Audio Routing during a Voice Call
* States: Audio Routing: STANDBY, HANDSET, HEADSET, SPEAKERPHONE, BLUETOOTH
Mic Mute: MIC_ON, MIC_MUTED
org.openmoko.VoiceCall:
* Goal: Abstract the fact that you need to talk to gmsd for a VoiceCall
Manage Conference Calls, put calls on hold, Mnage different Lines etc...
* States: ON-HOOK, DIALING, WAITING, TALKING, RINGING (incomming call)
This one is a quite complex one.
We will need to include hooks for Least Cost Routing, or Send Signals
to the Jurnal, etc...
org.openmoko.FaxCall (send and receive Faxes, integrate with CUPS ?)
org.openmoko.DataCall (CSD Data Call to other Neo or normal modem)
org.openmoko.Wlan (WLAN Present ? Power On / OFF, select ESSID)
org.openmoko.GPRS (To set APN, set status)
org.openmoko.USBNET (To sync?)
org.openmoko.IPNetwork (General Information of kind of Connection
(WLAN/GPRS or how cheap/expensive it is )
org.openmoko.SIP that will be a lot of fun...
org.openmoko.GPS (last known longitude, latitude, power on / off)
org.openmoko.Location (more elaborate, higher level (i.e. Home, Work)
based on GPS, WLAN ESSID, Area Code of Cell ID or Bluetooth Adresses
(PCs), whatever there is) These signals might be used to switch
profiles, etc...
I hope you get the idea. I would like hear what other think about this.
Maybe it would be a good idea to start documenting possible interfaces
in the WIKI ?
Cheers,
Thomas
--
Excercise 17:
If the human brain was simple enough for us to understand we'd be so
simple we couldn't understand.
Prove this by induction.
