Request for the 1.0 release

[Havoc Pennington]

Hi,

Decision to be made here. We had delayed 1.0 for a long time hoping to
get the DCOP/Qt interop issues sorted out before freezing ABI. However,
we had then decided to give up on that and go 1.0 anyway, because dbus
was getting widely used, and nobody was actively working on the DCOP
stuff. With Thiago now working on this actively, my take is that we
should give it yet more time (I know, it's been years, but what's a few
months at this point).

We might consider though a hard time limit. Thiago is it possible to
predict how much time we need to be confident that there are no
showstoppers from a Qt/DCOP perspective?

On specific items -

On Sat, 2006-02-25 at 13:22 +0100, Thiago Macieira wrote:
> Adding a couple more that I consider 1.0-blockers:
> - automatic daemon starting from apps
> 
> - Win32 & MacOS X official support

Do you think these will impact the ABI? I guess automatic daemon
starting could affect some semantic guarantees, such as the scoping of
the daemon to the session vs. to a session/machine pair, and of course
whether the daemon is guaranteed to exist. It may not change the actual
symbols exported from the lib, though. Win32 and OS X support hopefully
do not change semantics or symbols exported, though I can imagine them
adding symbols (we have some unix-specific symbols), and may reveal
unexpected UNIX dependencies in the public API.

The problem with both of these items is that 1) they are some work -
maybe not months of work, but at least weeks and 2) we don't have names
signed up to implement them. So if we make these blockers, they could
delay us indefinitely.

> - method calls with empty interface names: do we want to keep this or not? 
> Talking on IRC it seemed to me that this is legacy stuff and that we don't 
> want to keep it. However, it's in the spec and the libdbus library allows 
> us to do it.

The question here I think is whether any bindings rely on this to work
nicely. The idea was that e.g. in Python it might be hard to come up
with an interface name. But I don't know what Python bindings do in
practice.

>  The dbus server daemon, however, simply drops the message 
> with an assertion failure, causing my testcases to freeze.

Ouch, I thought the test suite covered this. Can you send in the
backtrace, or text of the assertion failure? Remember that ability to
crash the daemon is at least a minor security issue (you can break a
systemwide daemon and DOS some functionality of the OS).

> - standardise error names for property & method access: 
>   * no such object
>   * no such interface on object
>   * no such method on object/interface
>   * no such property on object/interface
>   * parameters don't match for method call
>   * access denied for property access (reading a non-readable; writing a 
> read-only, etc.)
>   * error setting property (invalid type?)

This should be very simply a matter of making up a name for each of
these in dbus-protocol.h then describing each in a sentence or two in
the spec. Anyone want to do the patch?

> - decide on overloading methods by interface and by parameters

This again is one of those "least-common-denominator" matters that come
up in the type system.

The thing about both of these is that I don't think libdbus or
dbus-daemon could ever efficiently or sanely "enforce" them - all we can
do is say in the spec that introspection data can or can't include them.
Thus, there's really nothing keeping a binding from doing whatever it
wants when talking to itself.

However, using these features would be potentially "unportable" or
"uninteroperable" in that some languages just can't really deal with
them at all.

Even when both languages can handle it, there are possible semantic
mismatches, e.g. in Java it would be fine to do something like:
  setValue(MyType1 value);
  setValue(MyType2 value);
but in C++ if you do this you are asking for trouble since null pointers
will be ambiguous:
  setValue(MyType1 *value);
  setValue(MyType2 *value);
There are probably better examples...

I think the issue of the same method name in two interfaces also plays
out differently in different languages; in Java (and Python?) I _think_
methods are resolved by name without reference to the interface. So you
could only ever have one implementation of Frobate(), even if several
interfaces specified it. In C++, I don't really know what would happen
and my Stroustrup is in the office so I can't look it up until
Monday ;-)

Anyway, for deciding what to put in the spec, I think the relevant
question is: what kinds of overloading will be impossible to handle in
certain bindings?

> This last issue generated quite a heated discussion in the #dbus IRC 
> channel on Friday: the spec doesn't say anything about whether 
> overloading methods with different parameters is allowed or whether 
> overloading methods with different interfaces is.
> 
> From what I'm told, the current decision is that we cannot have two 
> methods in one interface having the same name but different parameters, 
> but we're allowed to have two methods with the same name in different 
> interfaces and possibly with different semantics.

I added dbus_message_get_signature() (and overhauled the protocol
extensively) in order to support overloading, due to a suggestion by
Matthias Ettrich in a Nove Hrady conversation. So at least at one time
the intent was to allow parameter overloading.

My (not very strongly-held) opinion is that we should allow both kinds
of overloading, and bindings can always offer some lame way to deal with
it - for example, the GLib bindings could require the developer to
manually specify a different name for one of the overloads, or could
have a flag to insert type names into a proxy method name.

Bindings would need to be careful to avoid "changing ABI" when a new
overload is *added* though, i.e. if you have:

 Frobate(int)

and generate 

 proxy_object_Frobate(int value);

if Frobate(String) appears, you shouldn't now generate:

 proxy_object_Frobate_int(int value);
 proxy_object_Frobate_string(const char *value);

But how to avoid that I don't know, it almost requires that the code
generator treat this as an error and require the programmer to intervene
manually.

So this is more complexity, which I'm not a fan of. I do think this is a
hard-to-get-right additional burden for binding developers, and a lot of
bindings will have it messed up in practice, in addition to "semantic
mismatch" oddities. 

> Aside from that, the DCOP-vs-DBus issues won't start to come up until we 
> actually start porting KDE applications from DCOP to D-Bus. I'd expect 
> this to start within 1 month (hopefully), but the bulk of the 
> applications won't be ported soon. The old deadlock problem I've 
> currently solved by making any call to D-Bus allow reentrancy, which 
> means users must write code to cope with reentrancy any time they make a 
> D-Bus call.

Our experience with nautilus/bonobo was that coping with undefined
reentrancy was near-impossible; what you have to do in practice to be
safe is something like:

 ref_every_object_used_in_call_stack();
 make_reentrant_call();
 unref_every_object_used_in_call_stack();

And even that isn't really good enough (just as refcounting isn't enough
for thread-safety, you also need to be able to build atomic operations
using mutexes).

But it's probably a good bit easier if you're using refcounted smart
pointers as a habit, or a garbage collected language.

Havoc