Request for the 1.0 release

[Thiago Macieira]

Havoc Pennington wrote:
>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?

Hopefully, we'll start porting the DCOP stuff to D-Bus within one month. 
If we find large issues, it should be in the very beginning.

I don't expect to find many. The most complicated issues should be DCOP 
code that didn't use the standard interfaces and tools (dcopidl*), 
instead relying on doing stuff manually. And, of course, code that 
expects to be able to send any classes just by overloading operator<<. 
Both cases, though, should be solved in the application, not in the D-Bus 
protocol, library or binding.

So, with any luck, we can say that June should be ok. We don't have it set 
on stone, but we'll soon have a date when DCOP will be removed from the 
KDE libraries, thus forcing every application author to update his code. 
I expect that to be mid-April.

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

Given what has been discussed for #1, I expect it to be completed with a 
few lines of code. In fact, someone has proposed to write a patch, right? 
It should be a simple app linking to libX11 that gets the information 
from the root window. This app should probably be installed to 
${prefix}/lib/dbus-1.0, since it's not meant to be run by the user. Its 
path can be hardcoded in the library.

As for #2, I do consider it a critical issue because we simply don't know 
yet how big the impact of supporting those two platforms will be. If we 
knew it was just a matter of writing the low-level code, I'd be more 
comfortable.

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

A signal cannot be emitted without the corresponding interface name. If we 
make it so that methods cannot be called without the corresponding 
interface name, I fail to see the point in separating interface from 
method/signal name. Maybe the protocol should merge them in one single 
header field.

Then again, this would probably make my life as a binding maintainer a lot 
more difficult, and I'd expect other maintainers' too.

And, no, we don't rely on this to work nicely. There's no binding that 
does because the binding would simply not be working at all.

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

Yes:
arguments to dbus_connection_send_preallocated() were incorrect, 
assertion "dbus_message_get_type (message) != 
DBUS_MESSAGE_TYPE_METHOD_CALL || (dbus_message_get_interface (message) != 
NULL && dbus_message_get_member (message) != NULL)" failed in file 
dbus-connection.c line 2261.
This is normally a bug in some application using the D-BUS library.

It isn't crashing, though. It just drops the message silently (my 
connection isn't closed).

Note that the assertion is testing exactly for interface not being null on 
method calls, which the spec says isn't necessary.

The message was:
"l\1\0\1\0\0\0\0\4\0\0\0/\0\0\0\1\1o\0\1\0\0\0/\0\0\0\0\0\0\0\6\1s\0\6\0\0\0:1.146\0\0\3\1s\0\6\0\0\0method\0\0"
QDBusMessage(type=MethodCall, service=":1.146", path="/", interface="", 
name="method", signature="", contents=() )

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

The spec can mention what the least common denominator is, so that 
implementors are aware of what is interoperable and what isn't. But, as 
you said, if the author wants to use non-standard features, that's up to 
him.

I just don't think we should prohibit them in the spec, since the bindings 
or the bus cannot verify compliance.

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

Exactly. For any interface that we define in the context of 
freedesktop.org that is supposed to be called from any binding or 
implemented in any binding, the "least common denominator" rule must 
apply.

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

Just qualify your pointers. :-)
Section of qdbusintegrator.cpp:
   687      // output arguments
   688      QVariantList outputArgs;
   689      void *null = 0;                <---- qualified
   690      if (metaTypes[0] != QMetaType::Void) {
   691          QVariant arg(metaTypes[0], null);     <---- qualified
   692          params.append( arg.data() );
   693          outputArgs.append( arg );
   694      }

>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 ;-)

C++ allows you to call any class method, including those overridden and 
virtual ones. But, if you ask any C++ developer, they'll tell you it's an 
abuse of the language and breaks the OOP semantics, possibly even causing 
damage to the invariant.

Syntax:
  obj->method()    becomes:
  obj->Namespace::Interface::method()

I've solved this problem in the Qt bindings by calling a different object 
instead (an adaptor object that is attached to the real object).

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

Yes, and I thank you for that, because it made my life a lot easier! I can 
just take the message signature and compare to my list of available 
slots.

Overloading methods and signals by parameters work just fine as of today 
(I've just finished that code). I haven't merged it back to the CVS tree 
yet.

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

Another reason for specifying that interface authors should steer clear 
from them.

Just please don't ask me to forbid this in the automatic introspection, 
because it would be an expensive operation. In fact, the automatic 
introspection is likely to output the same method (same parameters, same 
annotations, etc.) more than once.

>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:

Indeed. One of the programming practices is to find solutions around 
reentering the event-loop. It causes a whole slew of problems that are 
difficult to track down.

But without it, I cannot even make blocking calls to myself, because 
dbus_connection_send_with_reply_and_block queues every message it 
receives, except for the answer.

Should the binding instead detect that the call was made to a local name 
and route the call directly, instead of using a DBusMessage? Or should 
libdbus do that (listening for all NameAcquired and NameOwnerChanged 
signals), bypassing the bus daemon?

-- 
Thiago José Macieira - thiago.macieira AT trolltech.com
Trolltech AS - Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060225/f015f61e/attachment-0001.pgp