Request for the 1.0 release

[Thiago Macieira]

Havoc Pennington wrote:
>That sounds like good news. Can we consider you our "point of contact"
>keeping track of critical dbus issues? Otherwise it's tough to be sure
>which things are considered truly showstoppers by the KDE core devs and
>which things maybe would be nice but don't matter too much, especially
>if lots of people start to post their opinion. So would appreciate your
>ongoing judgment/feedback.

Yes. Thankfully, I am in a good position to fulfill that role 
(announcements pending).

>> 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.
>
>You could probably continue to support operator<< using a struct or byte
>array in the dbus message, though of course using it would create
>interoperability issues.

I'm not taking the possibility away, but I'm not going to make it easy for 
the user. If they want to transmit arbitrary data, all they have to do is 
send a QByteArray. This includes random objects.

>What do you think about performance. I'm expecting that dbus is not as
>good as DCOP if you just do a "make tons of method calls" benchmark,
>though I don't think anyone has done it. I can imagine some people will
>consider this critical.

The anecdote is that, when we switched to DCOP back in the KDE 2.0 alpha 
days, it became known as "the day we made KDE 10 times faster", because 
DCOP was simply much faster than the previous solution.

Yes, D-Bus should be slower because it is a lot stricter. What we lose in 
simplicity we gain in interoperability, so I believe this is a positive 
change. (I wouldn't be maintaining the Qt code if I didn't believe that)

Besides, computers are a lot faster now than in 1999.

That said, however, my profilings of "make tons of method calls" have 
shown a great amount of time spent inside libdbus. In fact, in my tests 
(100 * 17 calls), calltree shows libdbus taking a large part of the CPU 
time. I did not use the --disable-everything parameters, though.

>libdbus can be made significantly faster probably, but I don't think my
>current libdbus implementation can be made as fast as DCOP or ORBit2.
>Essentially I optimized for flexibility, maintainability, and
>security/robustness at the expense of some speed. There are some things
>we could do like have a "don't validate anything, assume the peer sends
>correct protocol packets" mode - orbit and DCOP both basically trust the
>incoming data, I believe, and that saves a lot of cycles.

A malformed packet in DCOP will probably crash the target application, if 
not the server as well. The server inspects very little of the message 
contents: all it needs to know is the destination application.

So, no, considering libdbus is supposed to be used by root-privileged 
applications talking to non-root apps, it should be as secure as 
possible, at the expense of speed if necessary.

>> 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.
>
>Oh, that's just to avoid having to mess with string parsing. Seems more
>convenient. The get_interface()/get_method() accessors can also return a
>reference to the header in-place instead of allocating a new copy to get
>nul termination.

It was just a crazy idea. Don't do it :-)

>If nobody is then we may as well just require the interface name. It was
>optional only because it seemed potentially convenient for app
>programmers if they didn't have to type it.

Indeed. It stands to reason that if you're talking to a remote method, you 
must be reasonably sure of what it does. Adding the interface name makes 
it a binding contract: "I'm calling this method if and only if you work 
like the interface <foo> says it should work".

By the way, one of the criticisms I hear most often about D-Bus is the 
double- and triple-redundancy of the target when making calls. Example:

org.freedesktop.Hal /org/freedesktop/Hal org.freedesktop.Hal.Manager.foo

I think we're talking to Hal, but I'm not sure... :-)

>Eh, that assertion is just wrong, given the current spec. If we change
>this it will be right though and in fact should be added in a number of
>other places. The validation code will also need to reject messages that
>are missing the interface.

It has to match the one in dbus_message_new_method_call.

>Maybe some of the binding authors could try to chime in here with what
>will/won't interoperate with their binding... questionnaire ;-)

Answering for Qt 4:

> [ ] clients can use parameter-overloaded methods
Yes

> [ ] servers can implement parameter-overloaded methods
Yes

> [ ] clients can use interface-overloaded methods
Yes

> [ ] servers can implement interface-overloaded methods
Yes

> Any restrictions on overload details: ______________
Currently there are some restrictions on what kind of parameters can be 
passed on the C++ call stack (server parameter-overloading). Some D-Bus 
types are "blurred" to fit the limitations of QVariant. I consider this 
situation buggy and plan on changing it in the future.

>The Glib bindings already track the NameOwnerChanged stuff in order to
>emit destroy signals etc., so could add short-circuiting without new
>overhead in theory (though I think the current glib binding decision to
>just require async calls in this case is the right one for gnome)

What kind of destroy signals are those? I'm curious.

-- 
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/4d7db448/attachment-0001.pgp