Hi, everyone,
I posted a revised applicatino life-cycle manager design doc with more
detailed description in chapter 4. theory and practice. The original
discussin thread is here for your reference.
http://www.moblin.org/pipermail/dev/2008-September/002591.html
Thanks,
Horace
--------------------------------------------------
Application life-cycle manager design document
1. Introduction
Application life-cycle manager, codename Genesis, is part of the Moblin
application framework, exposing interface for application developers to
conveniently access application information, starting an application by
calling a single API, and processing various run-time statuses for each
running application.
It also maintains the application list for the applications that are
installed in the system, and updates the list whenever a change happens
in the monitored applications.
The purpose of the application life cycle management project is twofold:
1.Provide a set of utility functions, for applications on the
platform, to quickly and easily walk through the desktop files on a
standard Linux system, to expose applications and their categories.
2.Provide a mechanism for launching applications and tracking the
execution of those applications to watch for resource starvation, hangs,
unresponsiveness, etc.
2. References
Description of dependency libraries that are used in genesis are
referred to its individual web pages.
Libxml2: http://xmlsoft.org/
Libwnck: https://launchpad.net/libwnck
Glib2: http://library.gnome.org/devel/glib/stable/index.html
Gtk2: http://www.gtk.org/
Besides, Genesis follows strictly freedesktop.org desktop entry and menu
specification, and these specifications can be found at
Desktop Menu Specification:
http://standards.freedesktop.org/menu-spec/latest/
Desktop Entry Specification:
http://standards.freedesktop.org/desktop-entry-spec/latest/
3. System Overview
--exposed interface--
--------------------- ------------- ------
| App Entry | | | | |
--------------------- | | | Uti|
--------------------- | FS Monitor| | lit|
| Controller | | | | ies|
--------------------- ------------- | |
------------------------------------- | |
| Genesis Daemon | | |
------------------------------------- ------
Genesis is composed of four functional blocks, controller, app entry, FS
(file system) monitor, and utilities. Controller and App entry are two
components that exposes interface to developers.
Controller is the base of genesis, used to create and manage
applications list, which are installed in the system, start/terminate
applications by application name, and expose interface to provide
available categories list. App Entry is the object that stores and
provides desktop entry information extracted from freedeskop.org aligned
desktop files. Both Controller and App Entry objects are exposed to
callers.
FS Monitor is an internal object used by Genesis Daemon to monitor
changes happened in the directory where application desktop files are
stored. It captures the file system event notification send back by
inotify and forwarded the event to Genesis Daemon so that the change
will be processed properly.
Utilities object is a common object used internally. It implements
general functions that could be used by other objects in Genesis, like
converting path to uri and the contrary.
A daemon is designed to be running at backstage, initializing controller
instance, and monitoring specified directory where application desktop
files are stored. It will receive file system event notification from FS
monitor, and then call controller to process the changes, like updating
maintained applications list.
4. Theory and Practice
Genesis itself is composed of three modules and one backend daemon,
which will be started up during system booting up. Daemon will be run at
back stage, and call three modules to implement following features.
When daemon is started up, it will first initialize the genesis
controller instance. Genesis controller is designed as single instance
handle, so that each calls from user shares the same instance handle.
When controller is initialized, it will read through the directory where
application desktop files are stored, create an app entry data structure
for each application desktop file, fill in data structure by contents
that are read out from desktop file, and generate a list.
Interfaces exposed to developers are mainly two objects, controller and
app entry. Developers, who are going to use genesis, will firstly get
genesis controller instance handle that is initialized during daemon
start up. With genesis controller instance, a complete applications
list and categories list. Also developers could get a single app entry
data structure from a particular application entry node in applications
list, or search for the application entry node by giving application
name.
Besides, Genesis exposes interfaces to start up application by
application name or application binary path.
When giving an application name, Genesis controller will search for the
proper app entry node that contained the same application name, then
start up the application by spawning the process asynchronously.
When giving a binary path, Genesis controller will first search through
the applications list and see if there is any app entry node that
matches the binary path, if a node is found, genesis controller will
start up application directly using the same way with giving application
name; if no node is matched, Genesis controller will then create a new
app entry data structure, filling in the binary path to the data
structure, append the new app entry to the applications list, and then
start up the application by spawning the process asynchronously..
After application is started up successfully, its process id will be
recorded in the app entry data structure for later usage, like adding
watch function to get process exiting status notification. Genesis
controller will add a watch to each running application, and handling
the status returned with process ID. When application is exit or
terminated, signal will be captured in Genesis controller, and its
process ID will be reset to its default value.
Genesis will control application to be running only once in its whole
life cycle, so that when the same application is required to start up
again, Genesis controller will check its process ID first. If process ID
is a valid value, which means the application is running at the moment,
Genesis controller will bring its window on the top; if process ID is a
default value, which means the application is not started at the moment,
Genesis control will start up the application by spawning the process
asynchronously.
FS monitor object uses inotify to capture file system event
notification, which are initialized in Genesis daemon. With inotify file
descriptor returned, FS monitor will create a thread to watch the event
happened on inotify device. When there is event happened on inotify
device, FS monitor will read back the event, and forward it to Genesis
daemon to do proper operations, like updating applications list.
5. Design Considerations
5.1 Assumptions and Dependencies
Genesis assumes its user has basic knowledge of freedesktop.org desktop
entry specification and menu specification, and knows how to use GObject
interface.
Genesis is part of application framework in the whole Moblin 2.0
software stack, and depends on several basic libraries:
libxml2, the XML parser library.
libwnck, the Window Navigator Construction Kit is used to create pagers
and task lists, and monitor open windows, workspaces, etc.
Glib2, the core application building blocks for libraries and
applications written in C, providing the core object system used in
GNOME, the main loop implementation, and a large set of utility
functions for strings and common data structures.
Gtk2, a highly usable, feature rich toolkit for creating graphical user
interfaces which boasts cross platform compatibility and an easy to use
API.
5.2 General Constraints
In current stage, genesis will not consider Power Policy Management
related status report and handling. Following that, any hibernation or
power off status might not be handled by genesis.
Genesis parses desktop entry information, strictly following
freedesktop.org desktop entry specification and menu specification.
Those desktop files that are not aligned to freedesktop.org
specification might not be parsed correctly and adequately.
5.3 Goals
The first release of genesis will include following features,
1.Simple interface to acquire desktop metadata, following
freedesktop desktop entry specification.
2.Gracefully acquiring and managing metadata from non-freedesktop
aligned applications.
3.Simple interface to acquire primary and additional category list.
4.Support searching and returning application list by specified
category.
5.Start/Terminate applications by application name.
6.Immediate startup response by popping up a splash screen if there
is any, or a message banner if there's no splash screen.
7.Back-end daemon which supports automatic application list update
when any application is installed/removed/updated.
8.Application crash and hang-up detection, system resource starving
detection/quota enforcement.
9.Optimization on application entry metadata structure, reducing
memory footprint.
5.4 Development Methods
Genesis will be implemented using C language, and objects in Genesis
will be created based on Gobject.
5.5 Unit Test
Unit test will be included as part of genesis source release, and
guarantee exposed APIs work correctly. Unit test will includes
following areas,
Controller test
Test exposed APIs in controller, check returned controller instance
handler, and other returned values by given proper parameters; check
returned values by given improper parameters.
App Entry test
Test exposed APIs in app entry, read out app entry data structure, and
see if each field are filled in properly.
FS monitor test
Test fs monitor function, do operations in monitored directory, like
add/remove/modify desktop files, and check whether fs monitor object
reacted properly, whether or not file system event notification is sent
to daemon.
_______________________________________________
dev mailing list
[email protected]
https://www.moblin.org/mailman/listinfo/dev
