chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] Re: dbus:send bug


From: John J Foerch
Subject: [Chicken-users] Re: dbus:send bug
Date: Tue, 15 Mar 2011 19:20:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

John J Foerch <address@hidden> writes:
> There seems to be an error in dbus:send in the dbus egg.  As a test
> case, the first example given in the dbus egg docs will show the
> problem:
>
> http://wiki.call-cc.org/eggref/4/dbus#examples-you-can-test-with-qt

On further research, it seems that the bulk of the problem is that
dbus:send is entirely mis-documented.  That is, it doesn't do what the
documentation and examples say it does, but what it does do is still a
necessary and useful feature for the bindings to provide.  Here is a
fairly thorough list of what is wrong with the documentation, so
hopefully we can use this to fix it up:

  "Goals and Status"
  * send signals (messages)

This is misleading.  Signals are a type of message, but not all messages
are signals.

  "DBus in General"
  * signal: ... "A reply is not necessarily required."

This sentence should be omitted or changed.  Signals are one-way,
period.

  "Some of those would seem to be optional, because the total namespace
  ends up much deeper than e.g. a URL. However not enough testing has
  been done to confirm that if you leave out the service and the
  interface, for example, you won't miss them."

Interfaces are optional for both methods and signals.  Services are
required for methods, but not used at all for signals.

  "Exported functions"
  * dbus:send : send a message, and don't bother waiting for the
    response.

This is misleading.  It should say "send a signal" instead of "message".
The second clause is also misleading, because there is simply no
response to wait for.

Then the examples just need to be fixed up to use dbus:call instead of
dbus:send.  The second example uses dbus:send-and-await-reply, which
isn't even part of the api.  It seems to have a different call form from
dbus:call, so we would have to examine that more closely and figure out
what the intent was.

Thanks,

-- 
John Foerch




reply via email to

[Prev in Thread] Current Thread [Next in Thread]