Re: Gnome Session Services Framework

[Mark McLoughlin <markmc redhat com>]

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?

    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)

    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.

    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.

    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.


  - 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.

    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.


  - 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.?

    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?


  - 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.

    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.

     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?


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


	Sorry about the loooong mail :/

Cheers,
Mark.