Rootless Store

Appearance

Sources 与当前想法 ​

为什么叫 Sources ​

这一层在 Rootless Store 里，从界面到后端都统一叫 Sources。

原因很简单：对用户来说，他接触到的是“源”，是可以添加、查看、删除、读取信息、追溯下载来源的对象；对客户端来说，它处理的也同样是来源信息，而不是另一套割裂的命名体系。

所以现在更准确的表述是：

  • 前台模型叫 Sources。
  • 后台元信息也统一归入 Sources。

这样做之后，界面语言和技术语言会更清楚，前后端也不会再出现割裂命名。

Sources 的界面设计 ​

Sources 不是一个抽象地址列表，而是一个真正可管理的应用内对象。

目前这部分设计，主要强调以下几点：

1. 保留独立 icon 能力 ​

Sources 和 Plugin 一样，保留了自定义 App Icon 的接口。也就是说，每一个 Source 都可以像插件一样拥有自己的图标样式。

这个能力不会只是临时占位，而是会继续保留到后续版本中。它的意义不只是“更好看”，而是帮助用户更快地区分不同来源，提高识别度。

2. 完全贴合 MD3 设计 ​

Sources 的整体视觉采用了比较完整的 MD3 设计思路。包括它的胶囊样式、信息层次和交互观感，都会尽量和 MD3 的规范保持一致。

这样做的价值很直接：用户第一次看到 Sources 页面时，会感觉很熟悉，而不是像在使用一个风格跳脱、认知成本很高的极客工具。

3. 删除操作足够简单 ​

Sources 的删除也会和 Plugin 一样，尽量保持简单、直接、低负担。用户不需要自己反复确认“删完以后是不是还有文件残留”，也不需要去额外清理来源记录，软件会负责把相关后续处理掉。

Sources 的数据全部本地化 ​

Rootless Store 对 Sources 的记录是完全本地化的。

这些信息都会落到本地 SQLite 数据库中，因此不会因为设备退出、App 暂停或者界面离开，就让 Sources 的变化丢失。换句话说，Sources 不是临时界面状态，而是本地持久化的结构对象。

这带来几个直接好处：

  • Source 的状态可以稳定保留。
  • 用户添加过什么、删掉过什么，都可以被本地追踪。
  • 后续无论是同步看板、执行器还是插件列表，都可以围绕同一份本地数据工作。

网络层与后端思路 ​

在网络实现上，Rootless Store 当前更倾向于采用 Ktor 的 HTTP Client，而不是继续沿用传统的 Retrofit 与 OkHttp 组合。

这不是为了追新而追新，而是因为我们更希望整个实现路径更简单、更直接，也更符合当前项目的设计取向。我们不希望为了技术惯性，把可以更清晰解决的问题继续堆成更重、更绕的链路。

我们的立场很明确：应该用更简单的方法解决问题，而不是用更复杂的方法维持旧习惯。

至于后端层面，Rootless Store 会优先通过 Sources 的元信息去确认商店或来源的基础信息，并将这些信息记录到本地数据库中。也就是说：

  • 用户界面看到的是 Sources。
  • 客户端落地时依赖的也是 Sources 信息。
  • 本地 SQLite 会承担这些信息的持久化记录。

关于 Source Hoster、私有源与入口约定 ​

对于 Source hoster，也就是私有源的主人，我们也希望把一些发布建议写得更明确。

如果要更好地保护自己的知识产权以及代码所有权，我们更推荐优先采用 ELF 加上编译后的文件来发布。这样做一方面可以尽量防止知识产权被直接侵犯，另一方面也可以尽量把运行效率保持在更高水平。我们官方源本身，也更推荐这种写法。

当然，index.sh 的写法同样是社区默认接受的一种接口形式，所以这个入口我们也会继续保留。换句话说：

  • 更推荐的发布形态是 ELF 与编译后文件。
  • 兼容性和社区接受度更高的入口约定，仍然可以是 index.sh。

把 entry point 收敛到 index.sh，还有一个好处，就是 demo 会更容易被组织成类似 OneTime 的模型来执行。这样它可以看起来像 Ax Manager 的一个场景，方便理解和演示；但它本身又不必退回到“一次性执行完就结束”的状态。

也就是说，OneTime 更适合作为入口形式和 demo 方式，而 Rootless Store 整体仍然保留自己的常驻能力与持续运行目标。

这样设计的优势 ​

把 Sources 和本地数据库串起来之后，优势会非常明确：

1. 用户可以一目了然 ​

Sources 不再是隐藏在实现细节里的 URL 或配置片段，而是一个可以直接被看到、被识别、被管理的对象。用户知道自己加了什么源，也知道当前用的是什么源。

2. 更强调契约精神 ​

通过引入 Interface 这一层概念，Sources 不再只是“能请求到东西就算成功”，而是必须满足一定的描述契约、元信息契约和展示契约。这样整个生态会更稳定，也更容易扩展。

3. 下载行为可以追溯到源头 ​

当 Source 的信息、包的入口和本地记录都被绑定起来之后，后续下载行为就可以更自然地追溯到源头。用户知道内容来自哪里，客户端也知道该如何标记、归档和管理这些来源关系。

当前立场 ​

现阶段关于 Sources，这里有几条比较明确的原则：

  • Sources 必须是用户能理解的对象，而不是只有开发者能看懂的协议术语。
  • Sources 必须稳定本地化，而不是依赖临时内存状态存在。
  • Sources 必须优先简单，而不是为了兼容旧习惯不断加重实现复杂度。
  • Sources 必须保留去中心化能力，让用户自己决定添加哪些来源。

如果这一层做好了，Rootless Store 才不会只是一个插件运行器。它会真正拥有自己的 Sources 体系，也会拥有可以持续演化的生态入口。