Signals vs Calls

[wink saville]

Hello,

I was wondering how insiders of dbus see signals as compared to methods.
I've recently implemented an application that uses asynchronous messages
(signals) and have found that it requires a different programming style then
is "typical", but I find that is seems to me to have some advantages. The
one I find most compelling in my application is that asynchronous messages
scale very nicely. I was able to use exactly the same mechanism to
communicate between components running in the same address spaces, between
components running in different cpus across private communication channels,
between components running across a lan and between components and an
Interrupt Service Routine (this is an embedded/networked/multi-media
application).

I'm now thinking about how this relates to other messaging systems and if
there is something in the  Open Source Community that might be similar and
then I saw dbus in osnews, which brings me to here.

Soooooo, dbus looks quite interesting and it does support asynchronous
messages (signals) but it doesn't seem to be the primary focus. It would
seem that the developers of dbus feel synchronous messages are better where
as I've concluded the opposite. Obviously there isn't a correct answer it
more a matter of opinion, but I was wondering why the focus on synchronous
messages?

Thanks,

Wink Saville