Lib.rs

入门

聊天

开发团队在 cabal 上闲聊，这是一个类似 slack 的去中心化聊天室。要加入，请确保已安装 npm/node，然后运行

npx cabal cabal://bb10738176a7e893d28cc96536101697f9b0540d6132db18e8b110768b2cafe1

或下载 cabal-desktop 客户端 并加入聊天室 cabal://bb10738176a7e893d28cc96536101697f9b0540d6132db18e8b110768b2cafe1

版本

每个可消费的二进制文件应具有相同的版本，该版本应为当前发布的版本，它们应同时发布，以便最终用户可以确信他们正在使用每个 crate 的正确版本。内部 crate 可以逐个增加其版本。

可能的存储后端

我可以创建一个更通用的 "驱动器" 系统来存储任务。每个客户端都可以连接到任意数量的 驱动器 来存储任务。这意味着我需要以某种方式将协调整合到 hypertask 引擎中。这是一个不错的主意，但几乎肯定是在 v0.2 发售后要做的

• 平面文件系统
  • 简单
  • 与 Dropbox 等集成良好
  • 需要一个自定义服务器才能与网络客户端共享
  • 没有内置的共享机制
• Git
  • 可以附加到文件系统上
  • 如果托管得当，可以与网络客户端一起使用
  • 并非专为这个目的而设计
• Hyperdrive
  • 不稳定
  • 或者有点 rust
  • 内置了共享功能
    • 但只是一种守护进程式的方式
    • 需要一个静态服务
  • 无法与 HTTP 网络客户端一起工作
• Mongo
  • 简洁的数据库接口
  • 允许托管数据库存储您的任务
  • 命令行客户端和网络客户端具有相同的访问权限
  • SQL 数据库可能不会起作用，我想使用无模式系统，因此模式由客户端定义

是否更合理地拥有一个本地缓存和一个 upstream 驱动器，该驱动器可以用来传播更改？因此，每个客户端有两个组件：一个处理更新本地缓存，另一个将本地缓存与 upstream 同步？

自我笔记

具有客户端/守护进程架构实际上会导致更无状态和容错性更强的解决方案。客户端只从本地文件系统读取和写入，这意味着它可以始终运行，无论网络状态或状态一致性如何。守护进程应该能够以无冲突的方式与其他客户端同步本地文件系统，并且它受本地文件系统状态的控制。

网络交换格式 v1.0

在同步时，客户端将执行以下操作

1. 请求服务器已知每个任务的id到哈希的映射图
2. 为其自己的任务生成自己的id到哈希映射图
3. 比较哈希映射。
4. 如果没有冲突，则停止同步，否则，为每个任务解决冲突
   1. 存在三种可能的冲突类型
      1. 两者都有一个id，但哈希冲突
      2. 客户端有一个服务器没有的任务
      3. 服务器有一个客户端没有的任务。无论哪种情况，我们都可以遵循相同的逻辑
   2. 客户端发送它认为任务当前状态的值，或者如果它没有，则发送 null
   3. 服务器解决冲突，如果需要，更新其数据库，并响应它现在认为的任务正确状态
   4. 客户端接收到这个任务最新的正确状态，如果需要，解决任何冲突，并更新其自己的数据库
5. 一旦每个任务都解决了冲突，再次回到 1.

GET /哈希

请求

空

响应

{
  "pb67wndxge8293xd": "CONTENT_HASH",
  "px6zrs3z46b8e5pg": "CONTENT_HASH",
  "wbyzkrrrp7xb2rps": "CONTENT_HASH",
  "c6yx4mdzxm9cz7nm": "CONTENT_HASH",
  "dmnrx9gmdxhneq2x": "CONTENT_HASH",
  "tzthweareg9r6y5p": "CONTENT_HASH"
}

POST /任务/:id

请求

{
   "client_state": null | {
      "id": "pb67wndxge8293xd",
      "description": "example description",
      "tags": [ "test" ]
   }
}

响应

{
   "server_state": null | {
      "id": "pb67wndxge8293xd",
      "description": "example description",
      "tags": [ "test" ]
   }
}