about signals

[Olivier Andrieu]

Hi,

I found this interesting thread in the list archives: 
http://freedesktop.org/pipermail/dbus/2003-September/000488.html
http://freedesktop.org/pipermail/dbus/2003-October/000499.html

This is about the fact that one cannot send a signal *as* a particular
service, in other words signal messages always have a base service in
the SENDER header field. Seth suggested that the signal emitter set
the SENDER to a particular service.

I think that's quite reasonable in fact and that would more consistent
than the actual (unimplemented) solution.

There's a duality between METHOD messages and SIGNAL messages on many
aspects that is broken by this issue of services.
See, right now we have:

1) METHOD: many clients, one server (i.e. many senders, one receiver)
   SIGNAL: one emitter, many listeners (i.e. one sender, many receiver)

2) METHOD: PATH header designate the object the message is sent TO
   SIGNAL: PATH header designate the object the message is sent FROM

in the bus context:
3) METHOD: must set DESTINATION (or the bus will discard the message)
4) METHOD: must not set SENDER (the bus will overwrite it anyway)

I think it would be very consistent to have these rules for signals in
cases 3 and 4:
3) SIGNAL: must set SENDER
4) SIGNAL: must not set DESTINATION

See the idea ? METHODs cary information about the message receiver,
SIGNALs about the message sender.

Handling 3) for signals is easy: the bus checks that the application
sending the signal is the primary owner of the service, then discards
the message if it is not, or routes it to the other applictions.
Also, forbidding DESTINATION header in signal would clear one
inconsistency where a SIGNAL with a destination field is more or less
the same thing as a METHOD with a no_reply_expected flag.

Another advantage is that the complicated (and unimplemented yet)
tracking of service ownership at the bindings layer can be ditched.  I
think it's best to keep the bindings as simple as possible.  Requiring
the bindings to do complicated stuff like this tracking of service
ownership is dangerous because it makes it harder to write a binding
for another language/object system and bugs at this level could hurt
interoperability of applications using different languages.

What do you think of this ?

-- 
   Olivier