>Heyho, Hi morphis >as we talked already with some people about application management in >FSO we should now start discussing this in the public and define some >spec with all features we want in the end. I already thought about it and made a small diagram (far away from done) http://wiki.openmoko.org/images/8/84/Fsoarch.png
>I will start here with explaining my ideas. First of all we need a
>daemon doing all the application management. I think we should call it
>simply fsoappd. The daemon manages all things we have in mind with
>applications (btw. we should define what an application exactly is!).
>There is the lifecycle management of applications. An application has
>always a state which identifies the application as running, inactive or
>whatever. To come from one state into another one there are possible
>events (pause, hide, destroy, ...) which let the application change its
>state (for example, the wm choose another app to become visible, so the
>current app will get paused). We should define some rules an common
>agreements all application should share so we can keep our application
>management simple.
For performance optimation I would suggest, that we give kdbus a shot.
>Furthermore we need a way applications can communicate between each
>other. My idea here is to define common interfaces an application can
>implement. For example the org.freesmartphone.Dialer interface. The
>interface describes which DBus methods/signals should be implemented by
>the app. If one app needs the dialer, it requests the dialer via the
>fsoappd by a method called Request("org.freesmartphone.Dialer"). Each
>application has a file appinfo.config file where it defines which
>interfaces it implements. The fsoappd now searches through all
>appinfo.config files (they should be stored by each application in one
>common place) and tries to get one which implements the requested
>interface. If there is more than one fsoappd looks in a priority list
>which defines priorities for each interfaces (e.g. there are two
>dialers, one provided by SHR and one by a independent developer. The
>priority file now defines that the SHR dialer should be choose with
>higher priority than the other one ...). Finaly fsoappd starts the app
>for the requested interface in a not visible state. The app which
>requested the other app to start can now chose what it wants to do with
>the recent started app. Maybe it calles org.freesmartphone.Dialer.Show()
>to show the dialer application so the user can enter a number and call
>somebody.
>The application interface should be defined as xml spec somewhere. If an
>app does not implement any interface it should define at lest its name
>in the format like org.mycompany.mygreatapplicationname. The
>Request(...) method now looks even for an app called like the interface
>name is set.
Downloadmanager, packagemanager, etc. should be communicating
with relative system services.
e.g. networking shall not be shut downed, as long a download is in progress.
and fsosyncd shall be notified by networkmanager.
>As the application interface implementation is available as xml we
>should even provide a lib called libfso-app which implements all the
>interface in vala or your favourite language so you can easily use it.
Or even visual code generators. (Flowdiagram -> code)
>So far from my side. I have some more ideas, but will need some time to
>write them down.
Well done!
Keep on working like that. Thats great! ^^
>Btw. there is already a brainstorming page in the FSO wiki about
>application lifecycle management:
>http://wiki.freesmartphone.org/index.php/Brainstorm/LifeCycle and
>http://wiki.freesmartphone.org/index.php/Brainstorm/Launcher
I'll take a look
>regards,
>morphis
regards
leviathan
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
