setting sender on signals

[Havoc Pennington]

Hi,

I lost your mail in piles of others...

On Fri, 2003-09-26 at 16:10, Seth Nickell wrote:
> "mommy, that's not fair, org.freedesktop.DBus gets to send out signals
> as coming from a nice service name" ;-)

True, that's a bit odd.

> Is set_sender an internal detail of DBusMessage then
> not-for-use-by-clients? Or is there some other situation where this is
> legit?

Remember, the bus daemon is optional. The architecture is that the bus
daemon is one application of libdbus and uses only the public API of
libdbus.

libdbus does have some public API that isn't especially useful unless
you're writing a bus daemon, granted.

> If I do a call to message.set_sender(some_service_name), wouldn't it be
> reasonably easy for the bus to be fine with that as long as the
> base_service for my connection has acquired some_service_name?

Easy yes, but it means that either a) you force application developers
to always specify the service name when making a method call or emitting
a signal, which makes their API all fugly or b) you have inconsistent
behavior where some messages have the well-known name as origin and some
have the unique name.

The unique name is intended to avoid something like:

 app A acquires well-known service Foo
 app B acquires well-known service Bar
 app B sends method call to Foo with sender Bar
 app C takes over well-known service Bar
 app A sends method return to Bar
 app B doesn't get the method return
 app C does get the method return

To avoid this apps would have to track who owned Foo and Bar over time.
Which is of course what you have to do now to "connect" to a signal from
a well-known service. So either way you get this tracking problem.

However, the tracking problem should be possible to bury in libdbus or
its wrappers, so I don't think it will matter much to app authors.

I think it's broken to have it undefined whether the sender is
well-known or unique name, so my view is that the daemon should either
require or forbid a sender set by the sender app.

> Right, but that's why you want to filter on it: you want to say "tell me
> when app blah sends a signal". Otherwise this is a somewhat onerous task
> involving, as you list above, every client independently tracking
> service ownership changes. Perhaps it would be nice to have
> org.freedesktop.DBus.GetServicesOwnedBy(base_service) ?

Sure, that would be easy to add.

Havoc