Lib.rs

入门指南

聊天

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

npx cabal cabal://bb10738176a7e893d28cc96536101697f9b0540d6132db18e8b110768b2cafe1

或者下载 cabal-desktop 客户端 并加入房间 cabal://bb10738176a7e893d28cc96536101697f9b0540d6132db18e8b110768b2cafe1

版本

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

可能的存储后端

我可以为任务存储创建一个更通用的 "驱动程序" 系统。每个客户端都可以连接到任何数量的 驱动程序 来存储任务。这意味着我需要在 hypertask 引擎中 somehow 实现协调。这是一个很酷的想法，但几乎肯定是在 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" ]
   }
}