Re: Gnome Session Services Framework

["John (J5) Palmieri" <johnp redhat com>]

On Wed, 2005-07-13 at 11:42 +0100, Mark McLoughlin wrote:
> Hi,
> 	Just taken my first look at this stuff; some high level comments:
> 
>   - Its not entirely clear what the semantics of or the need for 
>     dependencies is.
> 
>     What it means right now, according to the code, is that a service 
>     isn't started until its dependency reaches the "running" state. But 
>     when does a service reach the "running" state? As soon as it has 
>     been spawned? As soon as possible after its shared libraries has 
>     been loaded and it can establish a D-BUS connection? Or when all 
>     its initialization is complete and it is ready to provide its 
>     service?

That is dependent of the service.  Services that are patched to use the
service framework can emit the service started signal when they feel
they have been started.  Services using the wrapper should be declared
started after they are spawned and enter their mainloop.  We are toying
with the idea of adding capabilities so dependencies can be started when
services can respond to specific requests, but that is forward looking. 

>     When using gnome-service-launch, the service reaches a "running" 
>     state as soon as it has been spawned. If all services like this, we 
>     get a behaviour similar to the current gnome-session behaviour 
>     where all services are spawned one after the other, as quick as 
>     possible (except for the delay we've introduced by making D-BUS do 
>     the spawning and not spawning the next service until we get 
>     notification that the first service has been spawned)

gnome-service-launch is a migration tool for the most part.

>     I think the intention here, though, is that services shouldn't be 
>     spawned until their dependencies have been fully initialized. So, 
>     e.g., we wouldn't spawn the panel until the window manager is ready 
>     to manage the panel windows. If that is the case, I'm not sure why 
>     we're doing this ... certainly in the case of the panel, there's no 
>     reason to delay the panel startup that long; the current behaviour 
>     of spawning the panel immediately after the window manager is fine.

Yep, we need to look at services and determine what the best dependency
relationship is.  One things we get with the new service framework is
the ability to profile startup times.  My demo at GUADEC showed this.

>     Looking at the list of potential session services, I don't see any 
>     dependencies of the "wait until foo is fully initialized" sort:
> 
>       metacity, panel, nautilus, vino, gnome-settings-daemon, 
>       gnome-volume-manager, gnome-screensaver, gnome-keyring-daemon, 
>       esound, assistive technologies, beagled, NetworkManager,
>       netapplet, resapplet
> 
>     Also, with the likes of Vino we'd want it to be one of the last to 
>     start up, but it has no real dependencies. So, should be add some 
>     arbitrary dependency (e.g. NetworkManager) to ensure it gets 
>     started up towards the end? But what happens if NetworkManager 
>     isn't installed.

Good question.  We might want to add some other semantics for depending
on things that are just enabled or even don't start up if such and such
is disabled.

>     I'm not sure what to suggest - perhaps rename Dependencies to 
>     StartAfter with "spawn immediately after" semantics, add a WaitFor
>     key if we really need the "wait until initialized" semantics and 
>     add a StartLast key for services that should be launched in a 
>     jumble after the important stuff? Hmm.

This is why I didn't want to propose the dependency stuff until
Gnome2.14.  Good that we are asking these questions now though.  I
figured the gnome-launch stuff would just happen after the normal
session for now and we don't worry too much about ordering.  

We might want to put in levels where each level is implicitly dependent
on the level below it for ordering.  Of course you run into dependency
loops where one service depends on a service in a higher level but you
can get dependency loops anyway and we need to figure out a way to
prevent these.

>   - I'd like to see support for conditional activation - i.e. that a 
>     service is only started if a given GConf key is set and that 
>     gnome-session monitors the GConf key during the session, starting 
>     and shutting down the service based on the value of the key. 
>     Applications for this would be vino, screensaver, esound, ATs etc.

Why not just send signals?  (see talk about capabilities above)

>     I don't think the "Enabled" key in the service file is the right 
>     way to do this. You don't want all these apps copying system files 
>     to the homedir just to tweak the Enabled key - think translations 
>     not getting updated, the file sticking around if the service is 
>     uninstalled, homedirs shared across multiple systems etc.

I think the enabled key might just be the default and then we can use
gconf or something else to override.

> 
>   - Importing the environment from ServiceManager into the service 
>     seems using the GetEnvironment D-BUS message like a really odd 
>     thing to do. What if the env variables affect the initialization
>     of some library which has already been initialized? What if the 
>     locale changes and we've already called setlocale() etc. etc.?

Ray can better answer this.

>     I think the solution is either to not use D-BUS activation at all, 
>     or somehow ensure that all important env variables are set before 
>     D-BUS is started. The latter probably makes sense, because if 
>     gnome-session has a different e.g. LANG from D-BUS, then doesn't
>     everything that uses D-BUS activation need to do this 
>     GetEnvironment trick?

Ray?

>   - The fact that every service needs two files to describe it bothers 
>     me. The way I'd expect it to work would be that you could add 
>     meta-data to the D-BUS service description and query the D-BUS 
>     starting service for services based on that meta-data.

Ya the two file this is kinda off but it was the best we could do to get
the idea off the ground.  Perhaps have a way to add arbitrary data to
the dbus activation file and have a bus interface for querying this
extra data.

>     i.e. org.gnome.Metacity.service might contain:
> 
>       [D-BUS Service]
>       Name=org.gnome.Metacity
>       Exec=/usr/bin/metacity
>       ObjectPath=/org/gnome/ServiceManager/Service
>       Interfaces=org.gnome.ServiceManager.Service;
>       GnomeServiceName=Metacity
>       GnomeServiceDescription=Metacity window manager desktop service
>       GnomeServiceStartAfter=org.gnome.SettingsDaemon;
> 
>      and gnome-session could query for all services which implement the 
>      ServiceManager.Service interface and query the meta-data for each 
>      of those services.

Sounds like a good plan with the caveat that we want to be stabilizing
D-Bus right now.

>      I've a vague recollection of this being discussed on the dbus list 
>      before, and I can imagine the arguments against it - this is 
>      gnome-session meta-data, it should only be in gnome-session; we 
>      don't want D-BUS loading heaps of translations; we don't want 
>      another bonobo-activation query language - but it does worry me 
>      that we'll end up with quite a few different repositories of D-BUS 
>      services and their meta-data (e.g. if panel applets were 
>      implemented with D-BUS instead of Bonobo, you'd have another 
>      repository)
> 
> 
>   - Services aren't displayed in the splash screen at the moment, which 
>     basically means the splash screen will be empty. Any plans to fix 
>     that or are we saying that the icons in the splash screen are 
>     effectively useless?

Splash screens are useless is the general sentiment.  Just start the
desktop ASAP.

>   - How do you switch WMs with this? :-)

Haha.  We will provide a WM switcher application ;-)  Capabilities would
work wonders here.  Just enable another WM, disable the other and
dependencies can wait on the org.gnome.Service.Capability.WindowManager
signal.  Of course we would have to add the ability to spew capabilities
to wrapper for WM's that don't integrate into the framework.

> 	Sorry about the loooong mail :/

Good points though.  These are the things we have to be thinking of.

-- 
John (J5) Palmieri <johnp redhat com>