設計多 backend 支援，同時支援 python 和 node.js about pime

[PCMan]

目前我腦中的計畫，也是希望可以未來可以做到不同輸入法分開安裝，甚至直接從網站下載
但這個的困難點是，跟系統註冊輸入法需要 administrator，而且 windows 不像 unix，使用中的檔案無法刪除或是覆蓋，所以想不靠安裝程式來安裝，又要兼顧安全性和相容性，會是非常浩大的工程
先求能動比較重要吧！python 和 node.js 其實都不大 (以現在的系統規格來說...)
真的不想包進去，還可以在 NSIS 安裝程式做 optional 即時下載安裝
包進去主要的考量其實是為了固定使用的版本，還有避免和系統上原有的版本衝突
算是折衷的方式。

[PCMan]

@jessy1092 @KenLuoTW
這部份目前已經在著手進行，在 multi-backend branch 內
目前有以下修改 (已進 master):

1. libpipe.dll 移動到最上層目錄，而不是 python 實做的目錄內
2. 原先一個 text service 提供多個 language profiles 的方式太過複雜，這部份目前在 text service dll 內的 c++ 處理，改成切換 language profile 就要斷線重連，server side 完全不需要知道現在是切換 text service 還是 language profile，反正啟動每個新的輸入法模組，就要重新連線，server 設計簡化很多，也比較 robust

即將會做的修改 (開發中):

1. 不直接寫死 server 位址，連線到 server 前，client 先連線到 PIME launcher，送出自己的 GUID，PIME launcher 會查詢這個輸入法模組在哪個 backend (python or node)，接著檢查該 backend 的 server 是否有啟動，若沒有則負責啟動 server，接著傳回 server 的 pipe 位址
2. client 從 PIME Launcher 查到正確的 server 位址後，進行連線。連線建立後就是 client 和 server 直接對聯，不會經過 launcher
3. launcher 不用隨時一直重新啟動 server process，各個 server backend process 也不需要常駐。有 client 查詢 server 位址時，Launcher 才檢查 server 有沒有在執行，若沒有就 on demand 啟動。

以上請參考

[PCMan]

@jessy1092 舉一個實例你可能比較知道如何接上 node.js:

1. 新酷音輸入法模組被使用者啟用
2. PIMETextService.dll 被 TSF 啟用，並收到新酷音的 GUID
3. PIMETextService.dll 以此 GUID 查詢 profile_backends.cache 檔，得知此輸入法是用 python backend
4. PIMETextService.dll 建立 client，連到位於 ".\pipe\ <user_name> \PIME\python" 的 pipe
5. 連線失敗，因為 python server 沒有啟動，於是 PIMETextService.dll 呼叫 PIMELauncher，要求啟動 python server
6. PIMELauncher 嘗試執行 python.exe 啟動 python server，並且在啟動完成後，送出 "ping" 指令，確定可以連線，接著才返回 PIMETextService.dll
7. PIMETextService.dll 重新嘗試連線到 python server，成功
8. 此後都不再需要 PIMELauncher 的介入
9. 用到一半 python server 當機，連線失效，PIMETextService.dll 回到 step 5，要求 PIMELauncher 啟動 python backend server

目前架構是這樣運作，node.js 應該很容易可以整合進來了

[david50407]

這部份是不是可以再獨立出來變成新的 sub-module?
把原先的 PIMETextService 與 libpipe 獨立出來變成新的 repository，如 NIME 等就不需要依賴整個 PIME 也可以針對 pipe name 之類的做更好的修改？

[jessy1092]

@david50407 之前跟 @PCMan 有討論過，的確是會更改 pipe name ，藉由 ime.json 設定，比如 新增 engine 欄位，設定 backend 是 python 或 nodejs (PIME or NIME) ，然後連不同的 pipe name。

目前比較麻煩的是 PIMETextService 需要 ime.json 作輸入法註冊，server 端也需要 ime.json 做輸入法設定，然後是經由 parse 整個資料夾去看有幾個輸入法，或許改成統一的 config file ，然後去指出有哪些 backend 與輸入法位置，然後 NIME 跟 PIME 也可以為各自的 sub-module。

ex.

- server/
  - PIME/
  - NIME/
  - config.json

[david50407]

如果是依據不同的 backend 來管理各自的輸入法清單呢？
ex.

- server/
  - PIME/
    - backend.json
  - NIME/
    - backend.json

然後 backend.json 裡面除了有該 backend 的資料（如：啟動方式等）以外，還存放該 backend 支援的輸入法，至於該 backend 要怎麼維護自己的 ime list 就看各 backend 怎麼實作（例如提供 ime list management cli tool 等）
因為輸入法應該是 depends on backend，但是如果到時候沒有可以用的 backend 應該也不能使用？

[PCMan]

目前有個初步想法是這樣
所有的 input method modules 裝在一起
input_methods/
然後各個 module 的 ime.json 內會定義：backend=python 或 backend=node
建立連線時，client side dll 不直接連線到 server 的 pipe
而是先連到 PIMELauncher，由 launcher 統一管理不同 backends 的 server 是否已經啟動
PIMELauncher 根據要求的 backend 種類，啟動對應的 python server 或 node server
接著 return 真正的 server pipe 位置。
接著，client side dll 建立 pipe 連到 launcher 回傳的 server 路徑
之後就是 client 直接和 backend server process p2p 溝通了
當連線中斷時，要重建連線，重複以上步驟，先連到 launher
這樣應該就可以 on demand 啟動不同的 backend server，
並且不同 backend 的 modules 都能混裝一起註冊，一起管理
不用分開成兩個專案了

[PCMan]

這樣的好處是，現有的 server code 完全不用改，ime modules 也不用改
只需要改 client side dll 和 PIMELauncher，就可以用完全 transparent 的方式實做出多 backends

[david50407]

那 PIMELauncher 要怎麼知道不同的 backend 要怎麼啓動呢？

[PCMan]

backends 數量不可能太多的，直接寫死就可以了吧! 安裝程式自帶一份 python 和 node.js 就行了

[david50407]

應該是說，到時候說不定會有其他的 backend 實作也想使用 PIME 這麼一套框架而不想要跟 python 或 node 的 backend 一起包，是不是應該把 Client 與 PIMELauncher 的部分抽出來變成一個可以另外安裝的共用元件。（把 PIME 當成是一套框架的話這樣做應該比較合適？做為無內建 backend 與輸入法的 framework）

這樣子使用者安裝的時候也可以自己決定要安裝的 backend，輸入法也可以設計成一個一個的套件讓使用者自己下載安裝（或是安裝程式協助安裝），還可以建立一個 backend 與輸入法的 Hub 讓大家可以在上面交換各自的方案，當然我可能想得太遠了覺得 PIME 太強大就是了 XDDDD

[jessy1092]

@PCMan Nice 我看到更改的 commit 了，這樣真的簡單許多

reference 一下關於 第二點的 commit:
cee329c

[PCMan]

@jessy1092 我之前只想說讓 C++ code 越少越好，只做 thin wrapper，剩下都丟去 server 做，但是其實把 TSF 內部的邏輯 expose 給 server 反而會讓 server 變複雜，所以就把這塊細節藏進 C++ 做了。
你的 node.js backend 應該可以做相對應的修改，只需要處理連線跟啟動特定 module，其他部份 server 不需要處理。

[PCMan]

剛完成了「初步」的多 backend 支援，為此現在的 ipc 機制有如下不相容的修改

1. PIMETextService.dll 原本連到 .\pipe<user_name>\PIME\PIME_pipe，現在改成連到 .\pipe<user_name>\PIME<backend 名稱>，目前支援的 backend 名稱有 python 和 node
2. 連線前 PIMETextService.dll 會載入 profile_backends.cache 檔案，依照輸入法 GUID 查詢使用的 backend 是 python or node，這個檔案目前是人工維護，之後可以在註冊輸入法時自動產生
3. PIMETextService.dll 取得 backend 名稱後，會先嘗試連線到該 backend 的 pipe，如果連線失敗，則會改連到 PIMELauncher 的 pipe: .\pipe<user_name>\PIME\Launcher，並發送指令要求啟動 server
   4.PIMELauncher 起動對應的 backend server 後，會嘗試連線，並且發送 "ping" 字串進行測試，成功連線後結果返回 PIMETextService.dll

Node.js server 部份需要做的修改:

1. 將 pipe 的名稱改為 node。即傳入 "node" 給 libpipe.create_pipe()
2. 處理來自 PIMELauncher 的 "ping" 指令 (回覆 pong)，還有 "quit" 指令 (結束 process)
3. 我們需要找一個好的目錄結構來讓 python & node 兩個 server 並存... @jessy1092 這我需要跟你討論一下，我不確定 node 底下模組要怎麼放

這次是底層 IPC 機制和架構的改變，@KenLuoTW @lyenliang 你們的倉頡模組部份基本上不受到影響，我測試過還是可用的。

Cheers!

[PCMan]

現在的架構除錯更容易，PIMELauncher 不再一直重起 server，只有在 client 連線失敗，要求重起的時候才會重起。所以可以 kill 掉 server，然後執行開發版的來測試，此時可以接著繼續輸入文字，client 會直接連上新啟動的 server