从 Decaid 还叫别的名字的时候起，我就知道有一个问题我们终究必须解决：

新的咖啡硬件层出不穷。

秤、传感器、磨豆机以及其他设备，都能为工作流程增添有用的东西。但如果每出现一种新设备都要在 Decaid 中直接支持，这种做法的可扩展性并不好。每一项集成都需要修改 Decaid 本身，然后再发布一个新版本。

更重要的是，这会让 Decaid 成为那些最了解自己硬件的人——设备厂商、爱动手的玩家和开发者——的瓶颈。

在这方面，Decaid 的前身 De1App 已经提供了一个有用的先例。

De1App 最初只是一个用 Tcl 编写的演示程序，后来不知怎么就变成了生产环境使用的软件。Tcl 有一个很有用的特性：它是解释型语言，新代码可以在运行时加载。这自然就让插件成为了可能。

Decaid 支持 JavaScript 插件已经有相当长一段时间了，但最初的实现是刻意做得很小的。插件可以对少量机器事件做出响应，但当时它们还不具备成为通用扩展机制所需的基础架构。

随着时间推移，我们开始讨论一个能力更强的插件运行时应该是什么样子。插件能否与传感器通信？能否连接其他咖啡设备？能否把这些信息提供给 Decaid、它的 API 以及它的各种皮肤？

当 Bookoo Motto80 开始交付到客户手中时，这些想法变得具体多了。

Motto80 提供了蓝牙 API，其中包括读取当前研磨设置的接口。这使它成为说明设备集成能带来什么的一个特别有用的例子：在萃取时自动记录研磨设置，在工作流程中显示这些设置，从 DE1 平板电脑上调整磨豆机参数，以及避免大家都熟悉的那种忘记上次用了什么设置的问题。

而且它不会是唯一一款利用这一点的磨豆机。我们还收到了针对 Bentwood 磨豆机的驱动支持，让这个新的运行时又有了一个可以在其周围成长的真实集成案例。

这也让那个更大的问题变得难以忽视。

我们不想只添加一个 Bookoo 专用的集成。我们希望 Decaid 拥有一种方式，能够支持这类设备，而不必让它们的驱动成为 Decaid 自身的一部分。

这项工作现在随 Decaid 0.9.0 一同到来。

这个版本引入了动态设备驱动运行时，使设备支持可以用 JavaScript 实现并由 Decaid 加载，而无需修改 Decaid 内核。

而且重要的是，这并不是一个磨豆机专用的系统。

驱动可以代表不同种类的设备，并把它们的能力提供给 Decaid。目标是让厂商和社区开发者能够独立地构建集成，而由 Decaid 提供通用的运行时、API 以及围绕它们面向用户的基础架构。

与此同时，0.9.0 还把磨豆机支持作为 Decaid 的一等能力引入，包括一个新的 /grinder API，用于与已连接的磨豆机交互。

两者的结合是我们最感兴趣的部分：Decaid 可以把磨豆机理解为一个设备类别，而实际的硬件支持则可以来自动态加载的驱动。

我们希望这能大大方便厂商、开发者和充满好奇心的用户去试验新硬件，并将其接入 Decaid 工作流程的其他环节。

我们还想在此基础上构建更多东西，但 0.9.0 已经奠定了地基。

而且，希望下一款有趣的咖啡设备不必等到 Decaid 发布新版本，就有人能够开始使用它。

~vid

图片来源：Soso 与 Yannick 🙏

p.s.：请您前往 dcamp 查看常规的发布公告，其中有更多关于插件的信息。