Re: callback functions in Emacs

[Michael Albinus <michael.albinus@gmx.de>]

Richard Stallman <rms@gnu.org> writes:

>     I'm playing a little bit with integration of D-Bus(*) into Emacs.
>
> It isn't feasible for me to browse a web site--what is D-Bus?  Why do
> we want to control it from Emacs, and do it by adding C code?

Quoting from the introduction on dbus.freedesktop.org:

---

D-Bus is an inter-process communication mechanism--a medium for local
communication between processes running on the same host. (Inter-host
connects may be added in the future, but that is not what D-Bus is
meant for). D-Bus is meant to be fast and lightweight, and is designed
for use as a unified middleware layer underneath the main free desktop
environments.

Unlike more heavyweight conventional messaging middleware, D-Bus is
non-transactional. It is stateful and connection-based, however,
making it "smarter" than low-level message-passing protocols such as
UDP. On the other hand, it does carry messages as discrete items--not
continuous streams of data as is the case with TCP. Both one-to-one
messaging and publish/subscribe communication are supported.

D-Bus has a structured view of the data it carries, and deals with
data in binary form: integral numbers of various widths,
floating-point numbers, strings, compound types, and so on. Because
data is not just "raw bytes" to D-Bus, messages can be validated and
ill-formed messages rejected. In technical terms, D-Bus behaves as an
RPC mechanism and provides its own marshaling.

There are two major components to D-Bus: a point-to-point
communication dbus library, which in theory could be used by any two
processes in order to exchange messages among themselves; and a dbus
daemon. The daemon runs an actual bus, a kind of "street" that
messages are transported over, and to which any number of processes
may be connected at any given time. Those processes connect to the
daemon using the library, and it probably wouldn't make much sense to
use the library for anything else. We'll be looking mostly at the
situation where applications (or more generally, clients) connect to a
full-blown bus.

Multiple buses may be active simultaneously on a single system. D-Bus
was first built to replace the CORBA-like component model underlying
the GNOME desktop environment. Similar to DCOP (which is used by KDE),
D-Bus is set to become a standard component of the major free desktop
environments for GNU/Linux and other platforms. A GNOME environment
normally runs two kinds of buses: a single system bus for
miscellaneous system-wide communication, e.g. notifications when a new
piece of hardware is hooked up; and a session bus used by a single
user's ongoing GNOME session. A session bus normally carries traffic
under only a single user identity, but D-Bus is aware of user
identities and does support flexible authentication mechanisms and
access controls. The system bus may see traffic from and to any number
of user identities.

---

If you run GNU/Linux (what I guess), you can see D-Bus messages by
calling "dbus-monitor --session" or "dbus-monitor --system" from a
shell (the latter one only if you're running Gnome or KDE).
dbus-monitor is contained in the Debian package dbus-1-utils, for
example.

Linux' HAL and HotPlug are implemented on top of the D-Bus system bus,
as interface org.freedesktop.Hal .

For Emacs, the D-Bus session bus is more appropriate. Very rough
examples how Emacs could use D-Bus:

- Work as server. Register in the D-Bus session bus an interface
  org.gnu.emacs (which is derived from default interfaces
  org.freedesktop.TextEditor and org.freedesktop.FileHandler). The
  implementation is parallel to the emacs server, but would react on
  D-Bus messages towards such an interface instead of emacsclient
  events. This would allow applications to contact Emacs directly,
  without even knowing that Emacs is the text editor to be called.

- Work as client. Communicate with the registered interface
  org.gnome.Keyring in order to retrieve passwords and keys from this
  data store on a reliable way.

- React on bus signals. Register for the session bus interface
  org.gnome.ScreenSaver. The signal SessionPowerManagementIdleChanged
  toggles between true and false; depending on that signal there could
  be an extension of run-with-idle-timer. It wouldn't check only for
  user input, but runs when the session is really idle.

A lot of other use cases are possible, this shall show you just the
possibilities. Given, that D-Bus is used by Gnome and KDE, I believe
Emacs would benefit from being plugged in into D-Bus.

>     One of the basic concepts od D-Bus is, that one could register a
>     callback function which is applied when there bis a signal on the bus
>     one has registered for.
>
> By "signal" do you mean the C-level signals that are handled
> by `sigaction'?

No. It is a special D-Bus message one can register for.

>     But that looks ugly to me. Isn't there another, more simple way to
>     evaluate Lisp code from inside a callback function?
>
> What do you mean by "a callback function"?  That is not an Emacs
> concept, so it doesn't specify the most relevant facts.  What exactly
> is going to call this function, when?

There are two cases a callback function is used. You can offer an
interface to the session bus, and register a service in the session
bus which implements this interface. "Registering" means that you must
specify a C function which is called when another application sends a
message to this service. Let's say you implement a C function
"open_file", and register it in the session bus as method "OpenFile"
of interface "org.freedesktop.TextEditor". Another application, which
wants to open a file, sends a message to that method, and Emacs opens
the file. The file name to be opened is passed inside the
message. Because the other application sends the message to the
standard interface, it doesn't need to care _which_ editor will do the
job.

The other case is when you register for a dbus signal. A signal can be
regarded as a multicast message send from an application to the
session bus. Emacs could register the C function "idle_changed" to the
signal "SessionPowerManagementIdleChanged" of interface
"org.gnome.ScreenSaver". Whenever the Gnome screen saver changes its
status, it sends the dbus signal (multicast message)
"SessionPowerManagementIdleChanged" with the parameter true or false,
and every registered function, including our "idle_changed", is called.

> If you're talking about C-level signal handlers, the usual way for
> them to run Lisp code is by queuing input events.

That's the way I will go.

Thanks to everybody who gave me information, and best regards, Michael.