Re: GNOME 2.10 module proposal: libnotify and notification-daemon

[Ray Strode <rstrode redhat com>]

Hi Jeff,

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

--
> Hi,
> 
> 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
> session.  
> 
> 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
>           uninstalled.
> 
> 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 
>           applications.
> 
> 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
> services-in-desktop.  
> 
> 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. 
> 
> --Ray
> 
>