Re: GDBus extension points (Was Re: GDBus/GVariant plans for next GLib release)

[Ryan Lortie <desrt desrt ca>]

On Thu, 2009-10-15 at 12:24 -0400, David Zeuthen wrote:
> Yeah, hmm, while this is theoretically nice and everything, I'm not sure
> it's worth the effort to do just yet. I think it's better to just ensure
> that libdbus-1 is available (and working) on all platforms where we care
> about GLib (e.g. Unix-like, Win32 and OS X).

I'd actually advocate approach #1.  It's extremely low-overhead.  After
initialisation, in fact, there is no overhead at all (compared to if you
had implemented the interface to the bus as an abstract class and
implemented it in the normal way).

> (Also, one side-effect is that all methods on GDBusConnection would need
> to use vfuncs with the incurred cost of doing so.)

vfuncs on abstract classes are extremely cheap (pointer dereference +
call).  Compared to the fact that we are sending something over DBus,
they practically don't exist.

> (Also, reimplemenations would need to do a lot of things that libdbus-1
> does and those things are not really specced out yet - things like
> looking up the bus address in the X server (or similar on Win32, OS X),
> autospawning etc. comes to mind)

Yes.  Buyer beware, certainly.

> Anyway, we should definitely leave space in GDBusConnectionClass (and
> GDBusMethodInvocationClass) for this so we can add an extension point
> later.

I'm slightly confused what you mean by this.  I was thinking that
DBusConnectionClass (for example) would itself be abstract with vtable
entries for all the stuff you might want to do.  The only reason to
leave space there would be the ordinary one -- the inevitability that
you will want to add some new functions some day.

On second reading, I guess you mean that you want to make the calls
non-virtual and leave space to allow for them to be made virtual in the
future.  This makes sense, except I hope you will consider that the cost
of making them virtual now is practically zero.

Cheers