Inter Process Communication (IPC)
During a first discussion it was decided that Oxide should be controllable via an IPC mechanism. This functionality will be inspired by i3-msg.
Description
An IPC mechanism for the window manager is required. This is neccessary for:
Taskbar
External libraries
Command line utility
Feature list
The following list includes currently proposed features
everything that is achievable via the keyboard (kill, move, launch…)
current state of the window manager including e.g. layout or windows
IPC integration solution
Since there are two types of events that have to be handled, there needs to be some separation between them.
One type are xevents, received from the X11 instance, and the
other one is custom events created by the user, received over zbus.
For this reason, each type of event will get its own loop on its own thread, which will await them and push them into a list shared between them. The events in this list will be taken care of by the window manager, who will execute the correct action based on event type and content.
IPC queue
Technical solution
The following sections describe the argument for the different IPC-mechanisms and libraries.
Requirements
As for the aforementioned use cases it will not be required to send large amounts of data. Only short messages will be exchanged between the clients. Also it is not expected that the IPC performance will have a significant impact on the usability of the system. Therefore some IPC options such as shared memory and semaphores will not be regarded as these options are not as easy to use and do not offer any significant advantages.
Possible IPC mechanisms
There are multiple different ways of implementing IPC on posix systems.
FIFO
work like normal pipes, but are a permanent file on the system
fasted regarded option
good library support
Unix Sockets
work like TCP sockets
very fast IPC mechanism
easy to use and inbuilt library support
D-Bus
high level IPC mechanism
based on unix sockets
widely used in projects such as Gnome and KDE
offers message queuing, tow way communication and is supposed to offer a easy to use interface
comparetively slow compared to FIFO or UNIX sockets
Key Takeaways
TCP Sockets are only about 16% slower compared to FIFO
IPC performance is in most cases not the bottleneck
Sockets allow for two way communication
Sockets are more widely supported
IPC interface should be abstracted, so that the IPC mechanism can be changed in a later stage
D-Bus should offer a high level, simple to use IPC mechanism
Conclusion
After a technical discussion with the team the conclusion came to that D-Bus is most suitable. The performance is deemed non critical in our use case and the ease of use will be benefitial for the project. None the less, the IPC interface should be created in an abstract manner allowing for a possible replacement of the underlying IPC mechanism.
Implementation
Available libraries
There seem to be two main projects striving to provide D-Bus support for rust.
official D-Bus rust implementation by the freedesktop.org foundation
pure rust implementation
extensive documentation
examples
wrapper library for libdbus -> libdbus dependency - examples
Conclusion
Zbus seems to have some advantages over D-Bus-rs, mainly: - official freedesktop.org library - pure rust -> no libdbus dependency - Extensive documentation - Due to being an official library, maintenance is most likely certain
Therefore we came to the conclusion to use zbus as our IPC library.
Conclusion
As IPC-mechanism dbus was chosen as most suitable. The rust library zbus has been chosen as implementation.