On Mon, 2008-09-01 at 23:48 +0800, Li, Horace wrote: > Hi, All, > > I completed a design document draft of application life-cycle manager, > codename Genesis. Application life-cycle manager is part of application > framework in Moblin 2.0 software stack, and you could find more detailed > description in the document. > > Please help to review the document and see if the information included > in the document is adequate and clear. Any comments are welcome. > > Application life-cycle manager project is currently available at > http://test.moblin.org/projects/genesis-application-lifecycle-manager. >
This looks very interesting and i've been browsing through the code that you've written. Most of these comments relate to the desktop file stuff rather than life cycle management Did you look into gnome-menus which is an existing implementation for dealing with FDO .desktop files: http://svn.gnome.org/svn/gnome-menus/trunk/ The main header file is here: http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/gmenu-tree.h?revision=876&view=markup It has support for a lot of the things that you seem to need including monitoring, etc. (If this is too heavy then you might want to take a look at: http://svn.o-hand.com/repos/matchbox/trunk/matchbox-desktop-2/libtaku/) I'd be concerned about having a central daemon that loads in the desktop files, parses them and then communicates with the details to a client. I can only typically imagine that only one client (the launcher) will care about displaying available applications. If you have to have a copy of all the data in both the client and the daemon you've just wasted memory with the addition of e.g. rpc overhead. In a lot of ways the life-cycle management parts of genesis are similar to what a session manager, e.g. gnome-session will do, including respawning crashed components etc. The code for gnome-session has been recently reworked to simplify some aspects and it now features a dbus API for the management. An alternative strategy i'd like to suggest for genesis is to focus only on the launching and life cycle and that the api for client (i.e. launcher) would be a very simple "run this full path" command. The handling of the .desktop files would only be for the launcher to deal with. Also, just in case you don't know about it: you should care about interoperating with the startup-notification api: http://www.freedesktop.org/wiki/Software/startup-notification Lots of ideas for you. Good luck! Cheerio, Rob _______________________________________________ dev mailing list [email protected] https://www.moblin.org/mailman/listinfo/dev
