支持多個 translator 實例的實現方案

[弓辰]

討論個問題：

計劃使 translator 生成多個實例，以實現混合不同的輸入法。

如五筆、拼音混合輸入，現今以反查的形式提供拼音，只能查表，不能支持智能語句、詞頻調整及記錄用戶詞組。如果要實現全功能的拼音和五筆混打，則要支持爲兩部 translator 書寫各自的配置信息。

以下提出初步的設計方案，及兩個問題。

一、爲區分多個 translator 實例，可選地在 engine/translators 裏面指定別名（alias）

形式爲

engine:

  translators:

    - table_translator@primary_translator

    - r10n_translator@secondary_translator

或是

engine:

  translators:

    - table_translator=primary_translator

    - r10n_translator=secondary_translator

此第一問。選取一個符號作別名的標記，沒有其他深意，哪個符號更合適。

未指定別名時，依照往常的方式讀取配置。

二、當爲 translator 指定別名時，又有兩種方案：

一種方案是將別名用作前綴代替 translator:

primary_translator:
  dictionary: wubi86
 
secondary_translator:

  dictionary: luna_pinyin 

又一種方案則在配置文件裏形成一個獨立的小空間

namespace:

  main_translator:

    translator:

      dictionary: xxx

把 namespace/main_translator: 的值封裝成一個獨立的 Config 對象，然後現有邏輯仍按原樣讀取 translator/dictionary: 即可。

前綴的方法看似簡便，卻有一個問題：

支持多個 translator 實例，把 schema 和 dictionary 的關係由多對一變成了多對多。

部署時，各個 translator 加載的詞典都需要編譯。

對比現狀：部署時會編譯 translator/dictionary: 所指的一部詞典；

至於 reverse_lookup/dictionary: 反查詞典雖然也需要編譯，

卻是通過指定 dependencies: 由其他依賴輸入方案來保證編譯。

依賴其他方案提供多部詞典，並不夠好：

試想有部「自定義短語」詞典，提供用戶自己定義的速記碼，輸入自己的郵箱等常用信息。他幾乎總是附屬於其他方案來用，爲編譯這部詞典專設一個輸入方案作爲部署時的依賴項，頗有些繁瑣。因此打算棄用 dependencies: 這個設施。

如果前綴是任意指定的，部署的時候，找到全部需要編譯的 */dictionary: 需要額外的操作；

如果集中到 namespace 一處，只需遍歷各「空間」，從中讀取 translator/dictionary: 即可。

看來今夜不能有個決斷，所以徵求一下各位同好的高見。

弓辰 <chen...@gmail.com>

Sent with Sparrow