FSO Taipei agenda
dsamblasomdevel at gmail.com
Thu Sep 25 00:19:06 CEST 2008
El jue, 25-09-2008 a las 00:22 +0800, Daniel Willmann escribió:
> [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,
> 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.
OMG, mix all this with the frontend Raster's has show us in the
comunity list and I will cry of joy.
PD.-It's only a TODO list, but it's a great one :) I will try to test as
soon as you began to release.
> Daniel Willmann
> devel mailing list
> devel at lists.openmoko.org
More information about the devel