Lib.rs

入门

聊天

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

npx cabal cabal://bb10738176a7e893d28cc96536101697f9b0540d6132db18e8b110768b2cafe1

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

版本

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

可能的存储后端

我可以创建一个更通用的 "驱动器" 系统来存储任务。每个客户端都可以连接到任意数量的 驱动器 来存储任务。这意味着我需要在hypertask引擎中 somehow整合协调功能。这是一个很酷的想法，但几乎肯定是我希望v0.2发布后做的

• 平面文件系统
  • 简单
  • 与Dropbox等很好地集成
  • 需要一个自定义服务器来与Web客户端共享
  • 没有内置的共享机制
• Git
  • 可以放置在文件系统之上
  • 如果托管得当，可以与Web客户端一起使用
  • 并不是专门为此目的而设计的
• Hyperdrive
  • 不稳定
  • 或锈色
  • 内置了共享功能
    • 但只有以守护进程的方式
    • 需要静态服务
  • 无法与HTTP Web客户端一起工作
• Mongo
  • 简洁的DB接口
  • 允许托管数据库存储您的任务
  • CLI和Web客户端具有相同级别的访问权限
  • 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" ]
   }
}