协议设计规范

在大多数 Wayland 协议的设计中已经应用了一些关键性的理念，我们简述一下。 这些模式在上层的 Wayland 协议和协议扩展中都有体现（至少¹在 Wayland 核心协议中是这样）。 如果您正在编写自己的协议扩展，那么推荐您遵守并应用这些规范。

原子性

Wayland 协议设计规范中最重要的是原子性。 Wayland 的一个既定目标是 "每帧都完美"。 为此，大多数接口允许以事务的方式更新，使用多个请求来创建一个新的表示状态，然后一次性提交所有请求。 例如，以下几个属性可以在 wl_surface 上配置：

• 附加的像素缓冲区
• 需要重新绘制的变更区域
• 出于优化而设置为不透明的区域
• 可接受输入事件的区域
• 变换，比如旋转 90 度
• 缓冲区的缩放比例，用于 HiDPI

接口为这些配置提供了许多独立的请求，但它们都处于挂起状态（pending）。 仅当发送提交(commit)请求时，挂起状态才会合并到当前状态（current）。 从而可以在单帧内，原子地更新所有这些属性。 结合其他一些关键性的设计决策，Wayland 合成器可以在每一帧中都完美地渲染一切，没有撕裂或更新一半的窗口，每个像素都在它应在的位置，静静地显示。

资源（Resource）的生命周期

另一个重要的规范是关于资源的生命周期的：尽量避免服务端和客户端向无效对象发送事件或请求。 因此，接口往往会给局部 resource 资源定义有关生命周期的请求和事件，客户端或服务器可以声明他们意图不再向该对象发送请求或事件。 只有当两边都同意释放，才能异步地销毁为对象分配的资源。

Wayland 是一个完全异步的协议，它只能保证同一发送者的消息按照发送的顺序到达。 例如，当客户端决定销毁其键盘设备时，服务端可能有多个输入事件正在排队。 客户端必须正确处理不再需要的对象事件，直到服务端同步。 同理，如果客户端在释放资源请求之前还存在其它请求，那么请求队列就必须以正确的顺序发送，避免操作操作空。

版本相关

Wayland 协议中的版本有两种模式：Unstable 不稳定版和 Stable 稳定版。 这两种模式的协议都向后兼容，但协议从不稳定版过渡到稳定时，会允许最后一次不兼容的变动。 这样给协议提供了孵化期，期间可以进行实际测试，最后大变动可以完善协议，增加日后²的可用性。

为了向后兼容，新的事件请求只能在当前接口协议的末尾添加，枚举同理。 此外，每个实现所用的接口事件，另一端必须支持。 我们将在第 5 章讨论如何确定双方接口的版本。