Re: GNOME 2.10 module proposal: libnotify and notification-daemon
- From: Ray Strode <rstrode redhat com>
- To: Jeff Waugh <jdub perkypants org>
- Cc: desktop-devel-list gnome org
- Subject: Re: GNOME 2.10 module proposal: libnotify and notification-daemon
- Date: Tue, 09 Nov 2004 09:46:21 -0500
> (That said, I agree with the dbus activation stuff, and hope we hear from
> Ray about his plans soon.)
Right now I'm working on other things (killing off the mound of open
redhat bugs in vte, gnome-terminal, xscreensaver, gdm, and gnome-
session), but I hope to shift gears to this as soon as I get the bug
mound down to a reasonable level.
Since you're interested, I'll paste a message that partially summarizes
the discussions I had with Jonathan and Mark a few weeks ago. When I
start working on this problem I plan to post something to desktop-devel-
list that is more detailed (and is more suitable for discussing).
> Since yesterday was named the RHEL5 meeting day and Mark was in town,
> Mark, Jonathan, and I decided to discuss the future of session
> management. These discussions were high-level and didn't dive much
> into implementation details.
> The two most pressing areas of concern so far regarding session
> management can be described:
> - services-in-desktop problem: gnome-session currently spawns a lot
> of hard coded services from main.c (gnome-keyring-daemon, vino, a11y,
> gnome-settings-daemon, etc, etc). Furthermore, with the inclusion of
> a lot of RHEL4 features there is a need for even more daemons like
> gnome-volume-manager, eggcups, kerberos-auth-dialog,
> NetworkManagerInfo, etc..
> Ideally, we'd have a dynamic system where the package of a service can
> drop a file somewhere during %install or run a command during %post
> and then the service is automatically registered for all the users on
> the system and the next time they log in it is started. Then
> similiarly when the package is uninstalled the file gets removed or
> the unregister command gets called in %postun and the service goes
> away without muddying up the user's session configuration.
> - lost-panel problem: We don't want users to somehow mess up their
> session file and be without a panel or other essential component of
> the desktop and have no way to fix it.
> We decided to define certain components of the desktop as one logical
> desktop shell. These components include metacity, nautilus, gnome-
> panel. Mark pointed out a fairly good way of seeing where the line
> between desktop shell and normal applications lay. Namely, if you are
> working, have a bunch of things open, save your session, and switch
> desktop environments, what programs should ideally be restarted and
> restored for you (note in practice, session managers from competing
> desktops don't share session information, and that's not a problem we
> are addressing right now)? The stuff you want to come back up is not
> part of the desktop shell.
> For our discussions, we redefined the word session to mean those
> applications that would ideally come back up. In this respect, the
> session manager does more than just manage the session, but it also
> starts services and desktop components which are independent of the
> After a little discussion it was agreed that the two problems above
> aren't independent of each other. Desktop shell components share many
> of the requirements and qualities of services:
> = Lifecycle management
> - Start early on in the login process
> - End when the session terminates
> - Restart automatically when the process dies
> (from crashes or being killed).
> - No duplicate copies running
> - session-manager shouldn't start a service
> if it's already running.
> - Services should be robust and quit if they
> are started and are already running.
> The desktop is unusable without desktop shell components, so they
> don't have the previously mentioned requirement:
> - Need to be able to be injected into user sessions
> automatically on package install, and also be
> easily removed from user sessions when service is
> They do however have an additional requirement that services don't, in
> general, have:
> - Need to be able to track and record session state.
> This is particularly important for metacity, since
> it collaborates with all other session managed
> So the decision was made to broaden the definition of service to
> include desktop shell components, rescoping the lost-panel problem to
> be a subproblem of the services-in-desktop problem, and not deal with
> general session management issues, but instead focus solely on
> This means that, where applicable, I am going to try to work within
> the limitations of the XSMP right now. As stated earlier, all services
> will be started by dbus activation. This includes desktop shell
> components, but once activated, the desktop shell components that
> currently save and use session state will continue to do so using the
> XSMP. These applications will have to be modified to use the
> SmRestartNever restart style and be changed to register with a sm
> client id that is retrieved at runtime over dbus rather than from a sm
> client id that is sent through the command line.
> The possibility of deprecating the XSMP was discussed in favor of a
> dbus based protocol, but Jonathan and Mark thought that the amount of
> work involved would be something that should be avoided if possible.
] [Thread Prev