about signals

[Havoc Pennington]

On Thu, 2004-05-27 at 09:50, Olivier Andrieu wrote:
> 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.

The issues I raised in those archived mails still seem relevant
though... ?

I think the conceptual complexity is that a well-known service name is
used to locate a _connection_ or _application_, a unique base service
name is used to _identify_ said connection/application, and a
connection/application plus an object path is used to identify an object
instance. Then of course signals are emitted by object instances, not by
connections/applications.

The root problem here is probably having both concepts "object" and
"connection/application" - and both "services" and "interfaces."

A service by convention implies certain object paths will exist and
support certain interfaces, but a service is really just a way to locate
a connection.

Making this more concrete:

Without the bus daemon, a connection could be on host foo.com port 9374.
With the bus daemon, a bus could be on foo.com port 9374, and a
connection could be on the bus on foo.com:9374 and with service name
blah.Blah.

i.e. really the service name is equivalent to port or socket filename or
other parts of the connection address. It isn't intended to be used
other than to locate and track connections.

Imagine that we didn't have the bus, and instead we had a bunch of
domain sockets:
  /var/dbus-using-daemons/org.freedesktop.HALDaemon
  /var/dbus-using-daemons/blah.Blah

This would be more or less equivalent to the idea of a service. If you
connected to the socket blah.Blah you'd expect it to be a particular
daemon, but you wouldn't expect to use the name blah.Blah on an ongoing
basis as you talk to it.

Remember signal emission/listening is supposed to work without a bus
daemon at all, in the context of just a direct 1-to-1 connection.
In that scenario the equivalent of keying your listener code off the
service would be changing behavior depending on whether you connected to
"host", "host.bar.com", or "localhost" to establish the connection.

Havoc