Re: Gnome Session Services Framework

[Mark McLoughlin <markmc redhat com>]

Hi Colin,

On Wed, 2005-07-27 at 16:03 -0400, Colin Walters wrote:

> On Wed, 2005-07-27 at 17:16 +0100, Mark McLoughlin wrote:
> > 
> > 	For various reasons I'm not entirely sure it makes sense to use D-BUS
> > notification:
> > 
> >   - 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
> 
> Well, not necessarily the session manager, but it could happen that we
> want inter-service messaging, like the battery panel applet querying
> gnome-power-manager.  

	Oh, absolutely. I'm not saying that gnome-session and these services
won't use D-BUS in some form, I'm saying that if gnome-session itself
isn't actually interested in activating a D-BUS service, then (given
other considerations) perhaps D-BUS activation doesn't make the most
sense.

> By using D-BUS activation we allow for these kinds of dependencies; the
> battery applet would automatically wait for the session bus to activate
> g-p-m when it sent a message to org.gnome.PowerManager or whatever.

	I don't see how D-BUS activation would help, assuming that the battery
applet itself would never try and activate org.gnome.PowerManager - i.e.
gnome-session would be the only agent which would start g-p-m, therefore
the battery applet would just have to sit and wait for
org.gnome.PowerManager to be acquired and it wouldn't make a difference
to the applet how g-p-m was started.

> >   - It actually winds up being quite complicated to do it this way. I'd 
> >     be worried about this extra complexity adding extra points of 
> >     failure
> > 
> >   - Because of the complexity, we need a library for the service side
> 
> I think if we fix the env bug we can probably avoid the library.  

	libgnomeservice non-trivial. If we use D-BUS activation, I really can't
see the library going away. Perhaps things would be a lot easier with
the new glib bindings, but I'd still expect it to be non-trivial enough
to implement at the service side that we'd want a library.

	Also, if we decided to implement it separately for each service we'd be
adding yet more points of failure.

> >   - We use startup-notification in order to be notified when the app 
> >     app has fully started up
> 
> Hm, so every service links to startup-notification?  That means they all
> have to have an X connection, which is a bit weird for some of them.
> Also this would make s-n part of the developer platform, right?  Maybe
> not a big deal, but something to consider. 

	Nah, services wouldn't link to libsnot, just like apps don't. If the
service mapped a window (e.g. the panel or nautilus) then the startup
sequence would be automatically ended by gtk+. If the service didn't map
any windows it would just have to call gdk_notify_startup_complete()

> >   - 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.
> 
> Hm...possible but kind of ugly...It seems a bit nicer to tell service
> developers to just implement an org.gnome.SessionService.OnShutdown
> method or something.

	Certainly not as "elegant" as using D-BUS, no. But having worked on and
with CORBA/Bonobo, I'm kind of wary of choosing one solution over
another just because its more "elegant" :-)

	Seriously, though. I'm not sure something like the panel needs to be
asked to shutdown at logout. I'm not even sure that it gets an XSMP
"die" message at logout now.

	Also, logging out as quickly as possible should be a goal. So sending a
D-BUS message and waiting for each service to respond wouldn't be ideal.

	I like the pipe thing because its just so foolproof and simple. I count
a total of about 15 lines of code in gnome-keyring to implement the
service side. And only services that really need shutdown notification
would use this.

Cheers,
Mark.