On Wed, Sep 03, 2008 at 11:43:28AM +0100, Tomas Frydrych wrote: > Rob Bradford wrote: > > 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. > > I would have to agree; the launcher, as the primary user, is best placed > to hold the application database to avoid doing RPC; if anything else > absolutely needs access to that database, it can then RPC the launcher. > However, if the launcher UI is done properly, there will be no need for > secondary ones; I would go as far as to say that a need for having > multiple launchers is symptomatic of suboptimal UI design, and it should > not be necessary to cater for this in the API.
I disagree, having multiple databases in the system is not good, it would be nicer to have all forms of meta data about user and system resources in a central database that can be reused from multiple processes. Xesam specifies RDF semantics for storing application info: -- Content, xesam:DesktopEntry Url: http://freedesktop.org/standards/xesam/1.0/core#DesktopEntry Parents: xesam:Content < xesam:DataObject Children: xesam:ApplicationDesktopEntry Fields implied: xesam:desktopEntryIcon, xesam:desktopMenuCategory Description: Desktop Entry(typically a .desktop file) All fields: xesam:desktopEntryIcon, xesam:desktopMenuCategory --- Content, xesam:ApplicationDesktopEntry Url: http://freedesktop.org/standards/xesam/1.0/core#ApplicationDesktopEntry Parents: xesam:DesktopEntry < xesam:Content < xesam:DataObject Children: Fields implied: xesam:applicationDesktopEntryExec, xesam:supportedMimeType Description: Application Desktop Entry All fields: xesam:applicationDesktopEntryExec, xesam:desktopEntryIcon, xesam:desktopMenuCategory, xesam:supportedMimeType (snipped from http://www.xesam.org/main/XesamOntology95) The advantage of using a centralised RDF (triplet) store for such information would be avoiding quite a bit of duplicated code and functionality between components of the platform. > > 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. > > Yes, I too think daemon should be as simple as possible; for the life > cycle management to work well, you want minimal overhead in the daemon > process. I agree here, a focus on managing the life cycle on the application makes the scope better. /Øyvind K. -- ▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△ 'Truth comes out of error more readily than confusion.' -- Francis Bacon _______________________________________________ dev mailing list [email protected] https://www.moblin.org/mailman/listinfo/dev
