Request for the 1.0 release

[Thiago Macieira]

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

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

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

The problem is that all three, individually, are necessary to their own 
extent:

- 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 peer
- 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 
org.freedesktop.Hal.Manager)

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, 
mainwindow#2, etc.

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

>http://dbus.freedesktop.org/doc/diagram.png
>
>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
>other.

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

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 
in "local".

>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 
is "destroyed").

-- 
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/20060226/3977b79b/attachment-0001.pgp