Re: Gnome Session Services Framework

[Ray Strode <halfline gmail com>]

Hi,
>     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?
A service isn't supposed to set its status to the running state until
it's initialization is complete and it's ready to provide all the
functionality it's dependents may need.

Until then, it should stay in the starting state.

>     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)
One thing I was going to look into when I had some free time was
investigate using libstartupnotification to know when a service
reaches the running state (passing an extra arg to
gnome-service-launch or something).

>     I think the intention here, though, is that services shouldn't be
>     spawned until their dependencies have been fully initialized.
right.

>     So,  e.g., we wouldn't spawn the panel until the window manager is ready
>     to manage the panel windows. 
Yup, exactly.

>     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.
Is it? what if the panel process puts up a dialog before the window
manager is fully started?  The panel shouldn't really be started until
the window manager can manage it properly I think.

>     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,
Well gnome-keyring-daemon in particular should probably just be stared
by its client libraries like gconfd is.

>       esound, assistive technologies, beagled, NetworkManager,
>       netapplet, resapplet
Any service that has non override redirect windows have a dependency
on the window manager.  Any service that puts an icon in the
notification area should probably have a dependency on the panel.

>     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.
Why does it need to be started at the end?  Is the answer that it's
non-essential for a usable desktop, so it can be started later to
speed up login time?  If so, then you really don't want it started
anywhere in the currently services lifecycle, but after the user's
session has started loading.

>     I'm not sure what to suggest - perhaps rename Dependencies to
>     StartAfter with "spawn immediately after" semantics
What does starting something immediately after something else buy us? 
It doesn't seem useful to me.
>     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.

I'm okay with calling "Dependencies"  "Wait For".  I'm not sure how
StartLast is useful.  I think what we really want (and please correct
me if I'm wrong) is the ability to say, "this service isn't important
enough to slow down the user's login.  Punt starting it until we've
started the user's session".  Is that correct?

If so, one solution is to make gnome-session provide it's own
org.gnome.Session service and just add it to the dependency tree as
necessary.  So then the ordering would be

fundamental services -> user's session -> non-fundamental services

>   - 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.
Yea, that was planned (but not implemented yet).

>     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.
Right.  "Enabled" was really just for setting the system default, I think.

>   - Importing the environment from ServiceManager into the service
>     seems using the GetEnvironment D-BUS message like a really odd
>     thing to do. 
Yea, I never really liked this much.  One solution that's been
discussed is to extend d-bus such that a dbus service foo can set a
default environment for its own activations (if a service starts a
program with execve it can pass an environment, why shouldn't it be
able to with dbus?).

Of course, that has the issue of "what if the activated dbus service
was already running from other means before dbus service foo tried to
activate it?"

>     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.?
Well, a service really wants to acquire a dbus name as early in it's
lifecycle as possible.  gnome_service_initialize needs to be called
really early on.  It's a blocking function and--like you've pointed
out--it changes the environment of the service, so it needs to be
called before setlocale, before the display gets open, before
gtk_init, before gnome_program_init, etc...

>     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?
Yea.  D-BUS should either be started with the right environment
already set up or there should be a way to pass the right environment
to dbus services being activated.

>   - The fact that every service needs two files to describe it bothers
>     me. 
me, too.  In practice though, I don't think it really matters that
much.  It would be nice if services used d-bus for other things beside
just getting started and stopped.  So if its right for services to
become bus accessible, then they're going to need the d-bus service
file anyway.

>     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.
> 
>     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.
A service can have many objects though, and each of those objects can
implement many different interfaces.  There isn't even any requirement
that all the objects a service has be known when the service starts.
It can create and destroy them at run time.

>   - 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?
I think Seth said that the splash screen is really rather worthless. 
I believe he said something along the lines of "users don't care that
the settings daemon is being started, just that their system is
actively making progress toward logging in".

I think it might be neat to have a shutter (or iris or whatever)
closed until the fundamental services are started and then finally
open up.

>   - How do you switch WMs with this? :-)
Bah.  Why do you go and have to ask a hard question like that? :-)
Well the answer is, I suppose, that if a service depends on a specific
service it should use a specific name (e.g., org.gnome.Metacity), but
if a service depends on a general type of service then it should use a
more general name (e.g., org.freedesktop.WindowManager).

--Ray