FSO Taipei agenda
Sudharshan S
sudharsh at gmail.com
Wed Sep 24 14:56:42 CEST 2008
Hi all. With regards to the vala frameworkd, I have pushed the initial
framework with my gsoc code as one of the subsystems (odeviced). The
code is there in the openmoko-gsoc2008 repository under git.fso.org in
case anyone is interested. P.s sorry for top-posting.
On 9/24/08, Daniel Willmann <daniel at totalueberwachung.de> wrote:
> 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
>
--
Sent from Gmail for mobile | mobile.google.com
More information about the smartphones-standards
mailing list