[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: GDBus/GVariant: well-known vs unique names
From: David Zeuthen <david () fubar ! dk>
Date: 2009-10-15 17:34:42
Message-ID: 1255628082.22298.65.camel () localhost ! localdomain
[Download RAW message or body]
On Thu, 2009-10-15 at 13:31 +0100, Simon McVittie wrote:
> On Wed, 14 Oct 2009 at 21:34:26 -0400, David Zeuthen wrote:
> > - Ideally make insane things impossible to do
> >
> > - e.g. only allow proxy creation for unique bus names - not
> > well-known names. Instead people will discover they should
> > be using e.g. g_bus_watch_name().
>
> I don't think using well-known names is insane; you just have to be a little
> careful. Forbidding them would break automatic service-activation, which is
> not only implemented but also explicitly mentioned in the D-Bus specification,
> so clearly Havoc didn't think it was insane either...
Yeah, of course. But no-one prevents you from using GDBusConnection to
invoke methods on well-known names. It's certainly not ideal because you
typically want to use a generated method on a GDBusProxy subclass.
Anyway, you raise good points about activation here. First of all, I
think we need to have GBusNameWatcherFlags with a member called
G_BUS_NAME_WATCHER_FLAGS_START_SERVICE.
> In practice if you're using the well-known name on a proxy, then you want to
> watch the name owner *as well* - the proxy could do this automatically?
It's very tempting to allow construction of a GDBusProxy (or subclass)
with a well-known name. Let's examine the implications. We'd need
- a G_DBUS_PROXY_FLAGS_START_SERVICE flag so you can specify that the
service with the given well-known name should be started if it
doesn't exist.
- a GDBusProxy:g-dbus-proxy-bus-name property with the name you passed
to the constructor. The GDBusProxy:g-dbus-proxy-unique-bus-name
property would then contain the unique name.
GDBusProxy:g-dbus-proxy-unique-bus-name would be NULL if exactly when
(e.g. if, and only if) there is no name owner.
- a GDBusProxy::g-dbus-proxy-vanished signal when the name owner
vanishes (and also notify::g-dbus-proxy-unique-bus-name)
- a GDBusProxy::g-dbus-proxy-appeared signal when the name owner
appears (and also notify::g-dbus-proxy-unique-bus-name)
- a new G_DBUS_ERROR_NO_NAME_OWNER_FOR_PROXY error to return when you
attempt to perform an operation while
GDBusProxy:g-dbus-proxy-unique-bus-name is NULL
- a g_dbus_proxy_reconnect() that can be used only when
GDBusProxy:g-dbus-proxy-unique-bus-name is NULL. It would just
call StartService()
- we'd still be using unique names inside GDBusProxy for connecting
to signals, invoking methods and listening to property changes. So
the race conditions would be mostly gone.
- construction of a GDBusProxy with a well-known name would never fail
- construction of a GDBusProxy with a unique name would still be able
to fail
So all this is doable... and I guess.. possible to implement in a safe
way. It kinda dilutes the g_bus_watch_name() and g_bus_watch_proxy()
APIs and might cause people to use the wrong APIs. But I think this can
be solved by throwing docs at the problem. Thoughts?
David
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic