Horace, Good start on the App life cycle manager. Few questions and comments below
"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." =>The meta-data and the instance specific information must be separated. If the meta-data and the instance specific information is separated there is not need to reset the process Id, after the application is terminated you do not have to store any history. "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." =>What's the motivation behind this requirement/assumption? We may have applications that may not be singletons and multiple instances may be started. Can you also call out as to if the XDG information is not available the specifics on the handling for the application life cycle and the meta-data you will store? There was an earlier comment about ALM implementing 3/22 XDG spec. The Moblin use case is the prime motivation for the part XDG implementation. This should be called out in the design doc. I suggest you to call out the security aspect of the process launching specified in the design document. Thanks, Guru -----Original Message----- From: Li, Horace Sent: Thursday, September 04, 2008 7:12 PM To: [email protected] Subject: Revised Application life-cycle manager design document 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
