Request for the 1.0 release

[Havoc Pennington]

Hi,

On Sat, 2006-02-25 at 22:51 +0100, Thiago Macieira wrote:
> 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.

It is pretty important to disable all the assertions and verbosity,
because I use a _lot_ of expensive assertions and debug spew.

valgrind is also somewhat misleading because the I/O takes a lot of the
time.

All this said, yes, it is kind of slow ;-) As bad as MICO I don't know.

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

I think we could have a dbus_connection_set_allow_peer_to_crash_me() and
the apps in a desktop session could set this when talking to the system
or session bus. The bus itself I'd prefer to keep the validation turned
on.

I already somewhat implemented this, if you look in
dbus-message.c:load_message() there's a "mode" set to 
DBUS_VALIDATION_MODE_DATA_IS_UNTRUSTED, if you change that then it will
skip most of the validation and one can profile whether it helps. If it
does help, there are probably a few other parts of the validation that
could also be turned off with more coding work.

The big win would be to just optimize the marshaling/demarshaling code
though, since that's what I made slow when adding recursive types.

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

Yeah, there are long threads about that in the past. My feeling is that
these things are the same as:

 - a process ID or application name ("bus name")
 - an interface name
 - an object pointer/reference

In fact a binding could implement things this way:
 - always take a bus name including "getpid()" in it
 - always use actual interfaces from the language as the interface
   name
 - just do "sprintf("/%p", objectPtr)" to get the object name

They all seem like useful items to make a distinction between to me.

Lots of people are deciding to have only 1 interface and 1 object in
their entire app, and name all of the app name, interface, and object
the same thing, so then it feels redundant. But it's not like you have
to do that... e.g. say you wanted to export all widgets in an app, you
would expect each widget to have its own object name, and expect to have
some different interfaces depending on the kind of widget.

It might be cute to have the idea of some kind of "default" interface
and "default" object so that callers can skip the interface and object
names, but nobody quite figured out how that would work yet.

I tried to draw a diagram once:

http://dbus.freedesktop.org/doc/diagram.png

but I think that just makes it more confusing for most people ;-)

I think the real objection is to namespacing all three of the items, no?
Namespacing the object name I agree may be overkill, but it isn't really
enforced iirc, if you want to name stuff /1, /2, /3 or /pointervalue
or /myobject you can. The purpose of this namespace is just to keep
multiple libraries/modules in the same process from stepping on each
other. 

For example a natural approach is to make a hash table of numeric object
ids like /1, /2, /3. But if the python and glib bindings both do this,
and it's in fact very common to write pygtk apps that would use both
bindings, it would break. So using /org/gtk/1, /org/gtk/2, etc. for glib
and /org/python/1, /org/python/2, etc. for python would fix it.

The bus name and interface namespaces though are the same
global-to-all-apps situation addressed by Java or C++ namespaces. So if
you buy into namespaces at all (I know some people don't) then these
ones seem appropriate.

One thing you could do in KDE is have the Qt bindings default to an
org.kde namespace, or have a setDefaultNamespace() call that kdelibs
would use to set org.kde; then for intra-KDE communication you don't
have to type all the namespace stuff, you'd only have to type it if you
talked to org.freedesktop or whatever stuff.

Something like:

 marshalCall(busName, iface, object, method, args) {
     if (!busName.contains('.'))
       busName = defaultNamespace + "." + busName;
     if (!iface.contains('.'))
        ... 

 }

you get the idea... it's sort of like "using namespace KDE;"

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

There's a signal on DBusGProxy called "destroy", which is emitted when
the app on the other end goes away. So people can connect a handler to
"destroy" and know when their proxy becomes invalid.

The GLib bindings have two kinds of proxy:

"for_name" is attached to a well-known bus name, like
"org.freedesktop.Screensaver" and should never get the "destroy" signal
- it's attached to the conceptual "screensaver service"

"for_name_owner" is attached to a unique bus name (i.e. a specific
currently-running process). So if the current screensaver program
exited, you would get the "destroy" signal and have to make a new proxy
if a new screensaver program started up.

"for_name" is simpler (and also avoids a round trip on proxy creation to
get the current name owner's unique name), but it can be bad in some
cases also (if you have an interface that assumes state across method
calls, and you get a different process in between calls)

At least, that's my memory...

Havoc