[ANNOUNCE] D-Bus 1.0 RC 2 (0.94) released

[Havoc Pennington]

Daniel Stone wrote:
> 
> http://ozlabs.org/~rusty/ols-2003-keynote/img39.html
> 
> Read until img56.html.  Really.
> 

Yes, I've read that before. However, the reality here is that we're 
dealing with a low-level untypesafe marshaling API written in C. So, 
there is no magic way to make it foolproof.

The route I chose was:
  - be 100% consistent as much as possible; the functions
    always take &value, not value, rather than varying by
    the type of the value
  - document how it works

The safer route would be to have append_string, append_int, etc. and 
don't have append_basic taking a void*. However, because this is a 
low-level API intended to be wrapped, that seems a little bit bloated. 
The void* version is probably more convenient for bindings in a lot of 
cases anyhow.

Another safer route would be to have a DBusVariant type in the public 
API, but I think that is somewhat bloated also. The variant type would 
also have to have either append_* or an append_basic method.

The intent is very much that apps don't use this API, even though 
everyone is because the glib bindings need a lot of work, or some people 
want to avoid the glib dependency.

Still, that doesn't make it right to shove a a large pure C convenience 
binding into libdbus itself. Instead, it makes it right for someone to 
do the work on the glib and/or pure C binding. I don't have time but I 
would love to see it.

> (After doing this, go back and check out the plain C bindings wrt
>  iterators in messages, particularly the part that requires you to hand
>  it a _pointer_ to a string, i.e.:
>  dbus_message_iter_append(whatever, "this api sucks horribly");
>  is broken, whereas:
>  argh = strdup("i cannot believe i'm doing this");
>  dbus_message_iter_append(whatever, &argh);
>  is correct.  Obviously.)

The way it works now, you can do things like:

DBusBasicValue value;
dbus_message_iter_get_basic(iter, &value);
dbus_message_iter_append_basic(other_iter, &value);

i.e. the void* serves as a simple variant type without introducing 
DBusVariant.

(Obviously the above example of copying message-to-message is 
artificial, but copying message-to-some-binding-specific-something is 
not artificial.)

Code generators can also avoid special cases here; they can just 
generate a template like:

void
myMethodStub(<TYPE> value)
{
    dbus_message_iter_append_basic(iter, &value);
}

instead of having to switch on the TYPE and pick the right thing to do.

The message marshal/unmarshal functions are very much designed to be 
used in stubs like this, not in application code. An actual application 
binding for C would not expose DBusMessage at all ideally.

Havoc