[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: Targetted signals
From:       Ross Burton <ross () burtonini ! com>
Date:       2006-06-13 15:08:21
Message-ID: 1150211300.28366.54.camel () localhost ! localdomain
[Download RAW message or body]

On Wed, 2006-06-07 at 11:02 -0400, Havoc Pennington wrote:
> > Cause the signal to be sent to both :1.2 and :1.3 (destination is
> > ignored, signals are sent to all interested clients), or just :1.2?
> > (destination if set is respected)?
> > 
> 
> What does the current code do? I imagine we thought about this while 
> writing it, but I don't remember.

I finally got around to writing a minimal test application (attached).
This demonstrates that signals with a destination set are sent to all
clients.

ross@flashheart ~/Local/mess/24/dbus
$ ./listener &
[1] 11712
My bus address is :1.67
[ now the listener is waiting for signals to arrive ]
ross@flashheart ~/Local/mess/24/dbus
$ ./fire-signal
[ without an argument dbus_message_set_destination() isn't called ]
Sending signal
Got the signal
Sending signal
Got the signal
[ the listener got the signal ]
ross@flashheart ~/Local/mess/24/dbus
$ ./fire-signal :1.67
[ sending the signal to the address of the listener ]
Sending signal
Got the signal
Sending signal
Got the signal
[ the listener got the signal ]
ross@flashheart ~/Local/mess/24/dbus
$ ./fire-signal :1.3
[ sending the signal to Tomboy ]
Sending signal
Got the signal
Sending signal
Got the signal

I'd really like it if signals could be send to specific addresses.  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.  At the
moment the server calls methods on the server, but this causes a method
return to be sent, which is not required.

The alternative would be for each signal to have an ID argument and
clients filter on arg1=cookie, but argument matching is currently string
only.  If this were extended to ints then that might be a usable design.

Ross
-- 
Ross Burton                                 mail: ross@burtonini.com
                                          jabber: ross@burtonini.com
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


["signaltest.tar.gz" (signaltest.tar.gz)]

gҎDmo0yOqb(t	"1D)rVlU5gtj;iT<)L	mNf[~m3ؒ:~U8snwscv:NW{CT@ \
"B00|@c&E@)DZm\:%vB,`;f\VՒ7M0ޏ(DZ~q?FO0h~ʜz	00d`(kf*O3,_:=>;W^0˷72S!t \
rB:+5vNBOK3ͳX(nAݏ[W1%(_($4 5w
UO
i+4sJXp4 \
tGI|ni^rE%Sy!KURQ߼$S6&]ݗ \
:B?z^!}<1%L)C:oUU>n"@+x(mᅦo>fx	s\ĕTo_ޒLf"P?P0f \
oT.t=d#m-pW꬘*x$yEfs[a#-VfSK[rhW \
efK7~D*ZfR[Zte/ax/z+N&7x}]cYROg;;8ѦcϽ|0.μ1*5!,gmd?
 ь'X(c2~|zH
]*y[Ph4Fh4Fh4Ygz(



[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic