Targetted signals

[Ross Burton]

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.

Interesting idea.

> >My 
> >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
-- 
Ross Burton                                 mail: ross at burtonini.com
                                          jabber: ross at burtonini.com
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF