Re: Gnome Session Services Framework

	The session services stuff uses D-BUS activation in order to start the
desktop at login. It works something like:

  - We request the service be started using StartServiceByName using
    its D-BUS service name

  - D-BUS launches the program and at some point the program acquires
    ownership of the service name

  - The session manager gets notified that its started successfully via 
    via the NameOwnerChanged signal

  - If we get a NameOwnerChanged signal later, we know that the program
    has crashed and needs to be re-started

	For various reasons I'm not entirely sure it makes sense to use D-BUS

  - We're not actually interested in using the D-BUS service acquired by
    the app - i.e. there isn't actually much of a requirement for the 
    session manager to send messages to the app

  - It actually winds up being quite complicated to do it this way. I'd 
    be worried about this extra complexity adding extra points of 

  - Because of the complexity, we need a library for the service side

  - That second data file describing the service

  - The env variables problem[1] - i.e. the session manager can't 
    (easily) set any env variables for the service

	So, just for the sake of discussion, here's a counter proposal for
something much simpler and low-tech:

  - The .desktop-service file would contain the command line for the 

  - The session manager launches the services directly with fork() and 

  - We use SIGCHLD to watch if the app has crashed and needs to be 

  - We use startup-notification in order to be notified when the app 
    app has fully started up

  - In the normal case, if we want to stop a service (e.g. at logout), 
    then we just kill it

  - If an app really needs to be notified that its about to be killed, 
    it could have a %p argument on its command-line which would cause
    the session manager to pass it the read side of a pipe which the
    app should poll() on. When the session manager closes its side, the
    app should shut down gracefully.



[1] - I think we'll wind up needing to fix this for D-BUS somehow anyway

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]