sgalal

+1 for the left form

输入方案的自动安装可以分为三个部分 **输入方案收集** 输入方案的作者将方案发布在 GitHub 上 运行一个 Web 服务器收集这些输入方案，并跟踪这些输入方案的变化 **输入方案列表获取** 客户端程序向 rime.io 指定 URL 请求输入方案列表，服务器返回 json 格式的输入方案信息。 **输入方案安装** 客户端程序根据请求得到的 json 列表，根据本平台的特点执行相应的操作。 例如在小狼毫中，可以 (1) 内置一个输入方案安装模块，提供输入方案选择功能，类似上述图片  (2) 根据用户的选择，从 json 中获取对应的输入方案的 URL 并下载...

本地似乎不需要额外的 GUI 程序。 例如在 Windows 平台上，可以在小狼毫中内置一个配方下载与安装模块，首先从 rime.io 得到配方列表（例如 json 的形式），解析后列出配方供用户选择。 在其他平台上（例如 Android），「从 rime.io 得到 json 形式的配方列表」这一步骤不变，只需各自实现 GUI 即可。而本来各平台的输入法就自带 GUI 功能，新增一个 GUI 模块并不复杂。

我不太明白爲什麼需要額外實現一個跨平臺的程序。 比如，當用戶在小狼毫中選擇方案總表中的 [biopolyhedron/rime-zhuyin](https://github.com/biopolyhedron/rime-zhuyin) 後，小狼毫下載 [詞庫文件](https://raw.githubusercontent.com/biopolyhedron/rime-zhuyin/master/zhuyin.dict.yaml) 和 [方案文件](https://raw.githubusercontent.com/biopolyhedron/rime-zhuyin/master/zhuyin.schema.yaml) 兩個文件，放置在 **【小狼毫】用戶文件夾** 中，並部署即可。 當用戶在同文輸入法中選擇同樣的方案時，同文輸入法下載同樣的兩個文件，放置在 **同文輸入法的用戶文件夾** 中，並部署即可。 在這一過程中，只有「用戶選擇方案總表中的某一方案」需要使用 GUI。 所以我認爲，各平臺的輸入法似乎可以根據各自平臺的特點，在程序中各自加入方案選擇和下載模塊。

以下是我设计的一种 Rime 方案列表的程序，类似 Python 的 PyPI。如果需要，我可以帮助实现： --- # Rime Package Index ## 简介 该程序是一个 Rime 方案索引，类似于 PyPI，运行在 **服务器端**，用于 **自动化下载** 和 **自动化更新** Rime 方案。 ## 可行性 Rime 的输入方案通常只包含以下三种文件： 1. 方案文件（`schema.yaml`） 1....

@laubonghaudoi > 請問這個配方列表，跟這裏 rime/home#336 所討論到的是一樣的嗎？ 是的，我的發言是對 rime/home#336 重新構思後的結果。 @BlindingDark > 根据设想，这个语言要“一次开发，三个平台都能运行”，跨 rime 平台，那么用 rime 客户端自己去原生实现就不行了，因为 Mac，Linux，Windows 的 rime 客户端用的语言技术是不一样的。 如我上面發言所述，不需做到這一點。 「一次开发，三个平台都能运行」是配方 **管理器** 的做法。而配方 **列表** 只需提供一個列表（以 JSON 格式），Mac、Linux、Windows 的 Rime 客户端分別以各自的編程語言解析...

@BlindingDark 我認為實現並不複雜。客户端要實現的基本邏輯如下： 1. 客户端初始化時，下載配方列表保存到本地；此後當用户提出更新配方列表請求時，或客户端自動檢測更新時，客户端向服務器請求新的配方列表保存到本地（服務器可加入時間戳功能，以供客户端確認配方列表是否被更新） 1. 客户端提供檢索和排序功能。檢索的功能是：若用户輸入的檢索詞是某一方案名稱或方案描述的子串，則客户端顯示該方案；排序的功能是：用户可以根據方案名稱、方案下載量、方案最後更新時間進行排序（最後更新時間需要服務器記錄，以便向客户端提供） 1. 當用户選擇下載某一方案時，客户端從服務器得到該方案的下載地址，並將方案所需的所有文件分別下載到該平台客户端的相應文件夾中。當下載完成後，客户端將下載文件的日誌記錄到配置文件中 1. 當用户提出確認更新時，若客户端發現該方案有更新，則提示用户。若用户確認更新該方案，客户端從服務器得到該方案的新版本下載地址（可能與原地址相同，亦可能不同），並將方案所需的所有文件下載到臨時文件夾中。下載成功後，刪除原版本的文件，再將新版本的文件從臨時文件夾中移動到指定位置。客户端將配置文件中原有的相應信息刪除，將下載新文件的日誌記錄到配置文件中 總而言之，客户端只需實現 **四種操作**：下載列表、查看列表、下載方案、更新方案。

@lotem > 1、這個服務器是必須的嘛？ > 我看客戶端要實現不少邏輯，他一直是主動操作的。是不是意味着設計存入數據庫的信息，以靜態數據文件的形式記錄在一個GitHub代碼庫，供客戶端查詢，也能提供相同的服務呢。 是必需的。因為只有使用服務器纔可實現統計方案下載次數的功能（及便於日後拓展其他功能）。如果服務器具有統計方案下載次數的功能，可以使用户對方案的流行程度有直觀的感受，提高用戶使用體驗。 > 2、如何更新數據庫中的信息。如，一位作者向代碼庫提交了新的修改。 需要服務器維護者手動更新。否則若方案作者更新了方案內容，而服務器上的列表沒有更新，會出現數據不一致的情況。

> > 實現並不複雜 > > 就算**开发**成本（可能）不高，但是**维护**成本一定很高。 > 假如更新了配方格式，如何确保每个客户端都能兼容呢？--- 再写三遍同样的功能。。。 小改動本來也不複雜，況且「更新了配方格式」應該是指「增加了字段」，這個對於 JSON 是向下兼容的，可以實現平穩升級。 > @sgalal 你说的中心仓库的方案也有点问题 > > > 客户端初始化時，下載配方列表保存到本地 > > 没必要，可能会很慢。用户想装配方的时候再请求，而且不要请求全部的，只返回推荐的即可。 不會很慢。例如你提到的 pacman 的安裝包數據更多，但是仍然是全部保存到本地的。目前 HTTP 請求大多使用 gzip 壓縮，實際大小非常小。 >...

上面提到客户端應該採用跨平台還是原生實現的問題，其實這個與我所説的 **方案列表** 無關。 一旦實現方案列表（或「中心倉庫」），那麼繼續採用 plum 現在的跨平台解決方案亦無問題。plum 從該列表獲取數據即可。