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, > 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. 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. > > Regards, > Daniel Willmann > _______________________________________________ > devel mailing list > [email protected] > https://lists.openmoko.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
