FSO Taipei agenda

Daniel Willmann daniel at openmoko.org
Wed Sep 24 18:22:14 CEST 2008


[Copying this mail to openmoko-devel as well to raise awareness]

Hello list,

most of the FSO team is now in Taipei and yesterday we collected items
we want to discuss/work on in the three weeks we will be here.

Here's the preliminary list of problems we want to tackle. If you have
any comments or questions please ask!

* Power management
* Inter subsystem communication
  * layering & means
* Rules
  * reconsidering yaml
  * granularity
* Preferences (-> OM 2008 integration?)
* Documentation and examples
* Tests acquiring current time (and timezone)
* Alarm/Wakeup
* GSoC integration
  * PIM
  * remoko
  * gestures
  * odeviced
  * ...
* VoIP
* Networking wrt FSO
* Merging vala & python in frameworkd
* security (SELinux and running frameworkd as non-root user)
* How do profiles and rules play together?
* Location (awareness)
  * Probably shouldn't be in ogpsd, but higher level
  * EnterArea/LeaveArea
  * reuse (parts of) diversity-daemon?
* PDU handling (PB + CB + testing)
  * Correct font for zhone (with CJK support)
* Enhancing SMS DBus API
  * TP-UDH (SMS Header) support
* FSO Consumer
* improve ogpsd (Gypsy) DBus API
* Milestone4 roadmap

We already talked a bit about power management and inter subsystem
communication/dependencies yesterday and came to the conclusion that
different resources (e.g. GSM) will Register/Unregister with ousaged and
provide a object path where that resource implements the interface
org.freesmartphone.Resource with methods Suspend, Resume, Enable,
Disable.
When ousaged finds it should enable or disable a device (based on the
policy and users requesting the resource) it will call the
Enable/Disable methods of the resource and that will take care of
saving state, initializing the resource and controlling power.
For complex resources like GPS and GSM we'll stop using odeviced calls
zu turn the device off or on, but for simple resources odeviced will
take care of everything (registering with ousaged, providing the
Resource interface, ...).
Suspend and Resume will take care of the necessary steps before and
after suspend.

ogpsd will implement the Start and Stop methods from gypsy and
request/release the resource accordingly so programs only implementing
the gypsy API will still be able to turn GPS on and off.

The whole usage tracking and resource management design is starting to
look awfully like an event based init system with dbus interface. We
should look out for improvements in that area and see if we can achieve
the same thing without reinventing our own mini init system.

Enabling the GSM resource should just power on the modem and
initialize it (+CFUN=4), keeping radio off. This is useful for airplane
mode where you want to browse your SIM contacts/messages.

Resources that ousaged should (could) control are:
 * BT, Wifi, GPS, GSM, CPU, Display, Network
The idea is that requesting the resource
- CPU prevents the system from suspending
- Display prevents the system from dimming the screen
- Network tries to get a network connection (this will probably need
more info about how expensive it can be)

I think that was all.

Regards,
Daniel Willmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/devel/attachments/20080925/4fa9d720/attachment.pgp 


More information about the devel mailing list