Request for the 1.0 release
thiago.macieira at trolltech.com
Sat Feb 25 15:46:55 PST 2006
Havoc Pennington wrote:
>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
That depends on the underlying OS having support for the TCP Security
Flag, as defined by RFC 3514.
>The big win would be to just optimize the marshaling/demarshaling code
>though, since that's what I made slow when adding recursive types.
Yeah, that's what showed up most often in my profilings: the recursive
>> org.freedesktop.Hal /org/freedesktop/Hal
>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
The problem is that all three, individually, are necessary to their own
- the service name is necessary, or you won't know which peer to talk to
- the interface name is necessary to define what semantics you expect from
- the standardised object name is unnecessary for general application
objects, but is so for standard services. We could just say "use /", but
what would happen if two services were merged into the same application?
Some bindings -- like Java -- won't allow you to have different semantics
in the same object
The problem arises when they are connected together.
If we allow empty interface names, callers could just ignore it when
talking to well-known objects. The call in my example would reduce to:
org.freedesktop.Hal /org/freedesktop/Hal foo
(since we know that /org/freedesktop/Hal implements only
And just as information, in DCOP, the distinction between object names and
interfaces was lost a long time ago. Just as with the Hal example, the
object name was mandated, so that callers knew what objects to talk to.
It even happened quite often that the object name contain the
word "interface" (prime example: the "MainApplication-Interface" object
in all KDE applications). This became the standard practice, so the whole
concept of interface was forgotten in DCOP, even though it is still
supported by the library.
When two objects of the same type were added to the same application, they
distinguished by appending a number -- for instance, mainwindow#1,
>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.
Interesting. This is the behaviour in DCOP.
It is implemented by making a call to an empty object name -- analogous to
the empty interface name case.
Of course, it doesn't have to be an empty name. It could be a default name
("/default" or even "/").
By the same token, the default interface case can be handled either by an
empty name or by a default name (say, "org.freedesktop.DBus.Default").
By the way, you've just reminded me of a common practice in DCOP that is
not possible in D-Bus, but I have no idea if apps rely on being able to
call a remote, default object. It would be a fragile behaviour anyways,
so I expect this not to be a problem to convert.
>but I think that just makes it more confusing for most people ;-)
It confused the hell out of me :-)
>The purpose of this namespace is just to keep
>multiple libraries/modules in the same process from stepping on each
Which they can already do by opening *different* connections. As I said, I
am contemplating always opening private DBusConnections in the bindings
to prevent this kind of "stepping on my toes".
>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.
Yes, I have something similar. When generating the automatic introspection
for an arbitrary object, the interface name is produced from the class'
Since Qt claims everything starting with Q as a namespace (:->), any class
starting with Q will see "com.trolltech.Qt" prepended. Everything else
will receive the application's organizationDomain and applicationName as
namespacing (those are two properties defined in the application object).
By the way, in case the user did not set the organizationDomain for his
app, the binding defaults to a prefix of "local"
(i.e., "local.MyClassName"). According to the recent drafts for Multicast
DNS (mDNS), the "local" top-level domain is to be reserved for link-local
resolution. I have abused the notion to determine that an interface is
local to an application, since no entity can register a DNS domain ending
>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.
How do you know when the object ceases to be valid on the remote app, but
the remote app is still there?
>"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)
Those are nice features. Currently, I have implemented only
the "for_name_owner" mode. I'll add to my to-do list.
This "destroyed" signal, does it behave like a D-Bus signal? I mean, I
know it's synthesised by the binding, but does it contain interface
information too? (owner and path are unique to the object, signal name
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
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060226/3977b79b/attachment-0001.pgp
More information about the dbus