Re: GDBus/GVariant plans for next GLib release

[Ryan Lortie <desrt desrt ca>]

Hi everyone,

On Wed, 2009-10-14 at 21:34 -0400, David Zeuthen wrote:
> There was an amazing amount of consensus; here's a brief list

I am in complete agreement with any point in the list that I am not
directly addressing.  Other comments below:


>  - 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().

There was some small amount of disagreement on this topic: particularly,
there was some discussion that it might make sense to have proxy objects
bound to common names in the case where the service is stateless (ie:
can leave the bus and be re-activated without anyone noticing).

>  - Make the code available in libgio (perhaps with the libdbus-1 using
>    implementation in e.g. GVfs through GIOExtensionPoint - maybe not
>    worth the effort)

This would have the advantage of forcing a good design upon us -- the
convenience API would be forced to have very low coupling with
libdbus-1.  It would also prevent future hackers from accidentally
introducing more 'surface area' between these components.

There are a few approaches we could take to this end.  All of them
assume that the user-facing API lives in libgio and that we use a GIO
extension point.

  1) We could include the libdbus code directly in libgio.so and
     internally register the extension point implementation.

  2) We could include the code for libdbus in gio/ but have it
     build a separate .so file that gets installed into the GIO
     modules directory.

  3) We could put it in GVFS.

>  - Ensure the provided code is thread-safe / can be used from threads
>    - e.g. deliver replies/signals/method-invocation in the thread where
>      the method was called from, signal was subcribed to etc.
>    - this may^Wwill include fixing libdbus-1 bugs

Using the per-thread 'default mainloop' stuff of course.


>    The API does not expose a GDBusMessage type since that would cause
>    unwanted API that would assist in using the API as a whole in a
>    wrong way (e.g. exposing on-wire details like message headers
>    can be nasty). Instead, the API is based on invoking/handling methods
>    and receiving/emitting signals.

I think we might want to have some sort of GDBusMessage class.  Here are
a couple of reasons why:

 - I think it is valuable to be able to register very low-level filter
   functions (or signal watches, or async reply handlers) that deal
   directly with the message as it came off the bus (including the body
   and the full set of headers).

 - This is useful for people who want to do other types of object
   binding on top of GDBus.

 - Maybe you don't want automatic GError conversion

 - Easy way to send a reply to a specific message

 - No need to pass many arguments to functions or to have the types of
   arguments varied by the sort of function (incoming method call vs.
   signal vs. async result, etc...)

This could be approximated with a GHashTable or GVariant dictionary (of
headers) and a GVariant (for the body).  Our GDBusMessage class, in
fact, could be little more than a wrapper around the two.


>  - I decided to represent wire-errors (e.g. DBusError) using GError
>    since that type is widely used both in C and language bindings. There
>    are facilities for recovering the D-Bus error name. We also support
>    transparent passing of any GError (a feature used in e.g. GVfs).

I agree that this functionality should be present in the low-level
bindings (for example, you almost definitely want to have it on simple
g_bus_make_a_call() interfaces) but it should also be possible to
shortcut it.

> Some notes on GVariant
> 
>  - GVariant is very pleasant to use
thanks :)

>  - GVariant needs to be LGPL2 (I believe Ryan has fixed this already)
Not already, but of course I will.

>  - GVariant doesn't use en_US spelling. I think this is a deal-breaker,
>    it needs to read e.g. serialize instead of serialise. Anyway, I'm
>    da_DK myself but...
I'm not sure I understand the reasoning, but if it really is a
deal-breaker, I guess I have to do what I have to do :p

>  - GVariant is a superset of a subset of the D-Bus protocol (!)
> 
>    1. GVariant is a superset because it handles e.g. 'maybe' types
"Maybe" some day we can get this support into DBus :)

Actually, GVariant is a superset of DBus in several other (more minor)
ways:

  - no nesting depth restriction
  - no message size restriction
  - no restriction that dictionary entries must appear inside arrays
  - the unit type "()" is a valid type

>    2. GVariant doesn't yet handle the new 'h' type (e.g. unix fd)

Holy crap!  This is insane!  I had no idea that this was going on
upstream -- I might have had something to say about it.

It seems kind of unfortunate that the DBus type system used to consist
only of things that could be serialised and now it consists of a special
case that can't be.  That's really difficult to deal with from the
standpoint of GVariant (which, really, is a serialisation framework,
after all).

Now that it does exist upstream though, I guess that means that GVariant
really ought to support it.  This is going to require some thinking....

>    Now, 1. has been discussed extensively on this list. I don't
>    have any position on it, really. I guess it would be nice to
>    either get the GVariant type extensions into the D-Bus protocol
>    or disable them before merging GVariant into GLib. I don't know
>    how that would affect other GVariant users.

Incidentally, the merging of the 'h' type into DBus shows that we
needn't be afraid of having a feature in the type system that is not
necessarily supported for all uses (ie: you won't be able to send 'h'
messages to a bus that you're not using a unix socket for).  I believe
we can have the same restriction for GDBus: have a 'this message is
unsupported' error if you try to do silly things like sending a message
that's too large.

>    We probably need to make GVariant support the 'h' type. I guess
>    it shouldn't be too much work but the devil is in the details.
>    Ryan?

I'm thinking about this, but it's going to be very strange.  I'm
confident that I can do it within the confines of the existing API so
this might end up being something that we only add later on (the feature
in DBus, after all, is *very* new).

>  - GVariant is very pleasant to use
>    - Good job Ryan!

Thanks again :)


> I'd like to ask if people can reply to separate parts of the mail using
> separate mails rewriting the Subject line as needed. Thanks!

You should have put that request at the top.  Now that I'm done writing,
I really don't feel like splitting it all up :)


Thanks for the summary, David.  Feels good to get the ball rolling.

Cheers