On Thu, 2005-07-28 at 08:14 +0100, Mark McLoughlin wrote:
> 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.
The difference is that the bus knows to hold the battery applet's
message until org.gnome.PowerManager appears, because the bus activates
(execs) org.gnome.PowerManager itself. If gnome-session is responsible
for starting things, then the bus, upon receiving a message for o.g.PM,
will just say "no such service", since it doesn't know how to activate
it. Now, you could argue that the battery applet should handle the
nonexistence of o.g.PM (and in general every app should handle the
nonexistence of various services), but it seems a lot nicer from a
developer point of view to be able to assume that these services will
exist when they're needed, and just error out (fatally, basically) if
they're not around.
I guess we could just try to ensure the dependency chain is right (start
things like g-p-m very early, before any applets or apps), and have
gnome-session watch NameOwnerChanged on the bus until each service is
started, but just using bus activation seems cleaner.
> 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.
Well, in general I think if we need a library we've failed. It just
shouldn't be that hard to implement a service.
> Also, if we decided to implement it separately for each service we'd be
> adding yet more points of failure.
I think we can get the required complexity small enough.
> 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()
Ok, but it still seems weird to have service programmers do this for the
various targeted services that don't use X like beagled. I guess this
isn't the common case though.
> 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.
We'd want a bit of metadata in the service file saying whether it needs
to be explicitly shutdown or it can just be kill()ed. This parallels
what we want for the system services to make shutdown fast.
> 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.
If we fix the environment variable issue I think it could be close to 15
lines. It should basically be:
conn = dbus_g_bus_get ()
bus_proxy = dbus_g_proxy_new_for_name (conn, "org.freedesktop.DBus")
if (!dbus_g_proxy_call (bus_proxy, "RequestName", G_TYPE_STRING, "org.gnome.Keyring", G_TYPE_UINT, &response))
lose(...)
if (response != 0)
lose(...)
Which is what any app which wants the unique-app effect is doing
anyways; e.g. Evince, Rhythmbox, and eggcups off the top of my head do
exactly this.
The above is from me looking at
static GnomeService *
gnome_service_new (const gchar *dbus_name,
GError **error)
and dropping the environment goo, assuming we fix that. Maybe I'm
missing something though.
Attachment:
signature.asc
Description: This is a digitally signed message part