ross at burtonini.com
Tue Jun 13 09:36:12 PDT 2006
On Tue, 2006-06-13 at 18:20 +0200, Thiago Macieira wrote:
> Ross Burton wrote:
> >I'd really like it if signals could be send to specific addresses.
> I don't really agree with that. You're thinking of signals like a kind
> of "broadcast": all parties receive it.
> However, signals are more like "multicast": only interested parties
> receive it. You just have to craft the signal emission so that the
> receivers can make up a rule to match them.
> Since you can't influence the service name, nor the interface name or the
> signal name, you're left with two items: the object path and the
> arguments (and signature). You've tried to construct the rule based on
> the arguments: I would recomment the opposite approach: make the signals
> distinct based on the object path.
> >use-case is the DBus port of evolution-data-server. When a live book
> >view is updated a signal needs to be sent to interested parties, but as
> >there can be multiple book views with different queries and the message
> >arguments can be large (up to 40 vcards), restricting the sending of the
> >signals to only the relevant clients would be a good idea.
> Without understanding what "relevant clients" means, there isn't much more
> we can help you with.
> But, for example, if this meant that "relevant clients" means "clients
> that have open queries on the book view that got updated", one solution
> would be to have one object path per book view. That means clients would
> listen to the signals coming only from the book views that they queried,
> because they would have queried according to the object path.
Exactly what I was trying to say. I'll try this. Sometimes the obvious
solutions are staring at you in the face.
> >At the
> >moment the server calls methods on the server, but this causes a method
> >return to be sent, which is not required.
> You can make a call with the "no reply needed" flag set. The receiver side
> can opt to not send a reply in that case.
Yes, but if you use the glib bindings the no reply flag is sent but
ignored by the receiver, so a reply is sent back. This is then received
by the process that sent the message in the first place, isn't expected
at all, so it then sends an error back. :) I've got to file a bug for
this, it took me all bloody day to trace down (with the log from
DBUS_VERBOSE no less, hasn't anyone fixed dbus-monitor yet?)
Ross Burton mail: ross at burtonini.com
jabber: ross at burtonini.com
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
More information about the dbus