是否有可能编写一个完全符合桌面通知规范（DNS）的通知服务器？

Question

据我所知，一些发送通知的程序会使用

Notify

调用

replaces_id = 0

一次，以获得分配的 ID，并且在下次调用

Notify

时，他们会提供

replaces_id

以便他们可以替换旧的通知。

（至少这是我从 ArchLinux 的 AUR 中观察到的 spotify 的行为。）

显然，通知服务器可以独立于迄今为止发送通知的程序而重新启动，因此它无法知道程序存储了哪些ID，并且当其中一个程序使用

Notify

 调用 

replaces_id != 0

 时，它们将实际上是在请求

不现有通知的 ID，这似乎违反了规范的一部分（请参阅第一个表的 DNS），

此通知旨在替换的现有通知的可选 ID。

因此就有了标题中的问题。

（另请参阅

这个问题我为 Dunst 打开，认为它违反了规范。）

Answer 1

完全符合桌面通知规范（DNS）？

实际上没有人称其为“DNS”，除非他们打算混淆读者，所以，我想+1律师。

显然，通知服务器可以独立于迄今为止发送通知的程序而重新启动

通知守护进程预计不会退出；通常它与桌面环境一起启动并持续运行直至注销。尽管这都是无关紧要的，因为通知一旦关闭或超时就会停止存在，而不需要重新启动整个通知守护程序。

当这些程序之一使用 Replaces_id != 0 调用 Notify 时，它们实际上会请求一个不存在的通知的 ID，这似乎违反了规范的一项内容

“replaces_id”的目的是防止随着程序状态变化而累积冗余通知（并且以比关闭/重新打开通知更美观的方式做到这一点），而不是为了替换通知而替换通知。在所有情况下，如果调用 Notify()，则需要显示通知 - 如果没有任何内容需要替换或更新（例如，如果先前的通知超时或被驳回，或者 ID 由于任何其他原因是伪造的），则应该出现新的通知，而不是呼叫彻底失败。

我认为解释“现有通知的 ID”是合理的，如果指定了不存在通知的 ID，则“未指定”现有通知的 ID，因此调用可以继续进行如果根本没有指定 ID。

（实际上，对于客户端来说，在每次调用 Notify() 之后无条件更新其存储的 ID 比显式检查它是否已经存储了 ID 更简单 – 这也是 libnotify （主要客户端实现）所做的– 因此，即使 Notify() 由于某种原因返回与原始 ID 不同的 ID，它也更有可能起作用。）