原本官方僅有 Kobo Forma 旗艦機型可以透過 Dropbox 下載自己存放的書籍。雖然我不是 Kobo 派的，但我仍然很好奇，於是便快速的瀏覽一下實作方式。
https://github.com/fsantini/KoboCloud
上述連結便是專案的原始碼，看起來有幾個重點：
01. Kobo 底層系統應該是使用 Linux
02. 此專案是使用 Shell Script 及 curl command line tool 達成目標
03. curl 版本為 7.35.0
04. 此專案最後會包成一個 KoboRoot.tgz 檔案，
05. 以 Google Drive 為例，放置書籍的資料夾不能設成限制，也就是要打開共用
至於打開共用會不會有安全性問題？個人認為是有一點風險，這就要看 Google Search 的威力，至少我剛才試著使用 "site:drive.google.com epub" 這樣的關鍵字查詢，我在幾頁之後，有看到一本賈伯斯傳可以下載。
（稍微 Google 了一下，看起來這樣的方式是不會被 Google 或是其他搜尋引擎找到，但我不敢保證。）
所以想要使用此方法的，記得不要把這個資料夾的連結分享給其他人，避免造成版權問題。
2020/06/29 更新
01. Kobo 的官方支援（Dropbox on Kobo Forma），有帳號認證的步驟，看起來好多了。
02. 另外目前最新 issue 列表，看起來 Google Drive 無法自動執行同步。
03. The curl binary is from https://www.mobileread.com/forums/showthread.php?p=3734553。
2020/07/01 更新
很久沒碰 Shell Script 了！剛才又看了一下 GitHub，順便回答了一個使用 Google Drive 的人的問題，希望可以幫助到他。如果這個功能好用的話，等到我的 PW3 掛掉，我可能就會用這種方式來開啟我的暗黑心法叢書，不過還要加上轉 KEPUB 的動作。
該網友的問題是他把他的 URL 放在設定檔的最後一列，而 get.sh 只能讀取有換行字行的列，故他的設定沒有被吃進去，所以才無法下載，很高興可以用我的破英文幫忙解決問題，留個連結以免忘記。
https://github.com/fsantini/KoboCloud/issues/31
至於為什麼要有換行字元？稍微 Google 一下，原來 read command 是用來讀取 Text File，而在 POSIX 的定義中，Text File 需要包括換元字元，故這也是 Script 讀檔時常會遇到的問題，果然是長知識了。
Text File
A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the newline character. Although POSIX.1-2017 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.
2020/07/17 更新
Kobo 版本：4.22.15190 (2020/6/22)
我用從母親那拿回的 Clara HD 測試 Google Drive，一開始似乎有些秀逗，但重開機幾次後就正常。
它的工作原理是利用 Linux udev 機制，故偵測到網卡時，就會執行指定的 Script，而該 Script 會去設定檔讀取使用者的雲端路徑，再透過 curl 這支很有名的工具把路徑裡面的每本書下載。
我現在都習慣在首頁打開 Wi-Fi，然後按下同步，之後切回我的書籍，沒意外的就可以看到新放的書了。
晚上實測刪除書籍功能，發現只是從本機移除，書籍仍然存放在雲端硬碟，故下次同步後，還是會被重新加入，所以仍需自行在雲端移除。
也許最好的方式是寫一個 UI 介面跳出，讓使用者自行決定下載的書籍，而不是一股腦的都從雲端全部下載，但這是個大工程。
目前 KoboCloud 只能做到不重覆下載檔案，無任何進階管理功能，但我覺得也比都沒有來得好。
2020/07/19 更新
現在雲端分享資料夾共有 14 本書，測試了幾天，目前遇到過 2 次問題：
01. 書名中帶有 "-" 這個字元，導致無法下載。建議除了中英文數字外，盡量不要有其他字元。
02. 在同一次開機中，Google Drive 有更新，但在 Kobo 不管按下幾次同步都無法順利下載新放入雲端的書籍。不過既然我們已經知道 KoboCloud 使用的機制是 Linux udev 機制，而原理就是當偵測到 Wi-Fi 變更時，便會執行 Script 做一些事，故我就強制開關 Wi-Fi，接著按下同步後便順利的下載成功。
另外，有使用 Kobo 內建的瀏覽器瀏覽 Google Drive 分享資料夾，雖然可以看到裡面的書，但卻無法順利下載，個人猜測是內建瀏覽器可能缺乏 Javascript 支援。
更新完此文章沒多久，又放了一本書進去雲端硬碟，這次就沒有那麼順利，一直無法下載成功，好奇之下，看了一下 .add/kobocloud/get.log，發現對 Google Drive 的連線被拒絕，可能是短時間內一直對 Google Drive 存取或是 KoboCloud udev 的機制讓 Script 一直重覆執行導致，可能只能等一段期間後再來嘗試同步？
過了 15 分鐘，同步總算順利成功，看來沒有一個獨立的 UI 會限制這個功能的實用性，也許可以利用不支援子資料夾的功能，把當下想看的書籍才移至分享資料夾，減少 curl 一直動作而被 Google 軟 ban。
2020/07/20 更新
也許 KoboCloud 應該要新增一個避免重覆執行機制，執行時就寫一個檔案到 Local 硬碟，執行完畢再把它刪除，如果是因為 Wi-Fi 變動導致 Script 被重覆執行，看到檔案就表示先前的工作仍未完成，忽略此次動作即可。
像一些知名專案，例如 Apache、MongoDB，印象中都有類似機制，只是他們是把 PID 記錄起來，避免重覆執行。
另外，為了確認 Linux udev 行為，我今天在開啟 Wi-Fi 後，並未按下同步，而是在等了幾分鐘後，切換到 Kobo Store 再切換回首頁，這時稍早新增的書就已經出現在首頁，這證明了我並未誤會 udev 行為，從 KoboCloud 設定的 rule 來看，增測到網卡時會去呼叫 curl 下載書籍，而偵測到本機 loopback device 時，則是會 mount 指定的資料夾，故其實是不用按下同步就可以看到新書！官方之所以建議按下同步，應該是認為這樣比較容易偵測到硬碟有新增內容。
想想也是合理，這個 patch 方式，其實很像工程模式，因為我們沒有適當的 Trigger 去觸發我們寫的程式，只好利用 Linux udev 這樣的機制來達到我們要的目的。
沒有留言:
張貼留言