Signals vs Calls

[wink saville]

Yes, when I said sync/async I was referring to blocking of Calls. I see, so
signals are "broadcasts", I missed that. 

If I have a Method with a void return type, no "out" parameters and set
NO_REPLY_EXPECTED in header.flags there still may be a return message?

You indicate that the use cases D-BUS is targeting "systemwide bus and
per-session desktop bus", but in the specification it says it works over
TCP/IP so the definition of "desktop/systemwide" includes LAN's at least.
But with the use cases you've mentioned it would imply to me that it wasn't
intended to be "optimal" for that use, although it does work. Is that a fair
statement?

Also the D-BUS programming model is an RPC with blocking symantecs, is this
correct? Although blocking is optional the programming model and the
implementation seems to be based on a typical method call.

Wink




-----Original Message-----
From: Havoc Pennington [mailto:hp at redhat.com] 
Sent: Monday, October 25, 2004 8:29 AM
To: wink saville
Cc: dbus at freedesktop.org
Subject: Re: Signals vs Calls


On Sun, 2004-10-24 at 18:41 -0700, wink saville wrote:
> 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?

I'm not sure what you mean by sync vs. async.

What I would mean by that is whether a process blocks waiting for a reply to
the message. For a method call with D-BUS, if you want to get the reply
asynchronously (don't block, read the reply when it arrives); or just ignore
the reply; you can do that. You can also set a "no reply expected" flag on
the outgoing call, which is just a hint that you plan to ignore the reply,
so it doesn't need to be sent.

Signals are notification and their main point is that they are one-to- many
instead of one-to-one. This means that a reply doesn't make sense (which of
the many would reply?), so normally you would not block for the reply, even
if you do choose to block for method calls. But you are not required to
block in the method call case either.

I would caution you that D-BUS is not a generic IPC system nor is it
intended to be. Its purpose is to be very good at the two concrete use-
cases we have in mind (systemwide bus and per-session desktop bus). 
It may *happen* to be good for other things, but it isn't designed or tested
for anything else really.

Havoc