[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: Detectin mainloop integration
From:       Alexander Larsson <alexl () redhat ! com>
Date:       2007-10-01 7:05:36
Message-ID: 1191222336.22332.8.camel () localhost ! localdomain
[Download RAW message or body]

On Fri, 2007-09-28 at 11:55 -0400, Havoc Pennington wrote:
> Hi,
> 
> Some thoughts:
> 
> 1) are setup/unsetup really doing a refcount? (so they have to be
> called a paired number of times?) I would say they should

Yeah, I think so. I'm sure there can be cases where different users want
integration on partially overlapping times.

> 2) is is_setup() useful?

No, because you don't know if it was "you" integrate() call that is
setup. And if it isn't you can't rely on it being there for as long as
you want.

> 3) should we add API to libdbus that is more like:
>    typedef struct {
>           DBusSetupConnectionFunc setup_connection_func;
>           DBusSetupServerFunc setup_server_func;
>           void (* padding1) (void);
>           ...
>    } DBusIntegrationFunctions;
>    dbus_set_integration(const char *name, const
> DBusIntegrationFunctions *funcs);
> 
>    An example of the difference here is that on calling
> dbus_connection_open() or dbus_bus_get(), the returned connection
> would already be integrated. For dbus_connection_open_private()
> probably it would not be. Without this approach, we probably need a
> bus_get() equivalent at least in the glib integration lib.
> 
>  This may be a "future elaboration" though, we could do just a
> setup_with_g_main() split-out from dbus-glib for now.

I don't see the point really. Its only useful for the shared connection
(you might not want a private connection tied to a mainloop), and its
not easier or less code to use this than to call _get() and then call
integrate on it.

> 4) I'd be inclined to stick this glib integration lib into the main
> dbus tarball. It does not seem big enough to me to mess with as a
> separate thing. I'm also inclined to eventually merge some parts of
> hippo-dbus-helper or some kind of C convenience lib into the main dbus
> tarball. Are there big downsides to doing so?

Downside is the glib dependency on building dbus. It won't be an actual
package dependency, but it might still cause weird things with build
orders for e.g. distros.


_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
[prev in list] [next in list] [prev in thread] [next in thread]