This crate implements Wayland functionality.

Sketch of architecture

The piece of code running all the business is Engine. It sets up everything and handles requests from clients as well as the rests of application. Upon client connection Engine creates new

• skylane::Client, structure registering handlers (representing Wayland objects) and dispatching client requests to them and
• wayland_frontend::Proxy, structure used for sharing information between handlers, a state of client.

Proxy is shared between handlers as RefCell.

Two interfaces were introduced:

• Facade, for requests from clients (downward?) which is implemented by Proxy and
• Gateway, for requests from application (upward?) which is implemented by Engine (dispatching request to correct Proxys) and Proxy (making actual request to client).

So one Engine holds many Clients holding many (cell) references to Proxy, but at some point Engine must be informed that client created surface. For this purpose Engine and all Proxys hold (cell) reference to single Mediator.

Details of threading are left for application. wayland_frontend may be configured to receive in one thread and send in other or do everything in one thread. What is however sure accepting new client can not be done in DisplayEventHandler and handling requests can not be done in ClientEventHandler as it may require mutating dharma::Dispatcher, so handling is decoupled from processing using dharma::DirectSender.