Leo Editor 與 Fossil SCM

已經不記得用了Leo Editor 多少年了, 現在只要是寫架構性的內容 (網誌, 簡報, 程式) 都少不了它. 現在透過 leovue 與 leointeg 的逐步開發, 下一個階段的網際化 Leo Editor 似乎已經指出一些方向.

循著相同的發展路徑, Fossil SCM 應該也要走相同的網際化路線才對.

客戶端與伺服器端的整合

這裡所謂的網際, 指的是全球資訊網架構中, 伺服器與瀏覽器之間的整合, 也就是 Web-based 的意思.

而所謂的客戶端, 也就是瀏覽器, 能夠向伺服器取資料, 也能透過介面更改伺服器中的檔案內容.

只是隨著電腦硬體功能不斷提升, 虛擬技術與網路普及的發展, 客戶端與伺服器端之間的角色扮演, 越來越複雜, 近端的電腦原本只是擔任瀏覽器的角色, 向遠端的 www 伺服器取用資料或修改資料, 但是近端的筆電, 只要適合的軟硬體, 就能啟動 www 服務, 讓近端的 remote desktop 上的伺服器, 使用瀏覽器返回取用或修改筆電上的資料.

換言之, 現在的電腦軟硬體在網路的加持下, 早已經既是客戶端, 同時也可以是伺服器端, 重點在於要有足夠的軟硬體與實際情境的需求.

再回到前面提到的 Leo Editor, 原本只是單機上的大綱編輯器, 或者是採程式方法處理任何資料整合的 IDE, 但是透過 leovue, 可以將單機上的資料, 從瀏覽器上取得, 至於 leointeg 則更進一步透過 Typescript 將 Leo Editor 的編輯, 拉進 Visual Studio Code 的生態圈, 未來將可以再透過 Code-Server, 讓 Leo Editor 能夠融入未來客戶端與伺服器端整合的大未來, 也難怪 Leo Editor 的發明者對於這項發展抱持高度期望.

Fossil SCM

焦點轉回 Fossil SCM, 這個用來管理 SQLite 原始碼的分散式版次管理作者, 曾經在比較 Fossil SCM 與 Git (用來管理 Linux 原始碼) 的文章中, 要大家思考:

When deciding between these two DVCSes, you should ask yourself, "Is my project more like Linux or more like SQLite?"

亦即: 假如開發的程式套件接近 SQLite 理應採用 Fossil SCM 來管理, 而不是一昧使用 Git.

況且, Fossil SCM 儘管小但是所具備的功能卻很強大, 以前述客戶端與伺服器端的整合趨勢而言, Fossil SCM 加上 Flask 網際程式, 已經能夠滿足機械產品開發團隊的協同設計需求.

當然, 假如 Fossil SCM 的 ANSI C, 加上 Flask 的網際 Python, 若能再加上 leointeg 的 Typescript 以及機械導向的 Rust, 真可謂老中青三代同堂, 彼此截長補短, 未來網際宇宙 (Web Universe) 上的產品開發, 肯定比二十一世紀的觀落陰 (Meta Universe) 要更實際一些.

精巧的 Fossil

在 Fossil SCM 的原始設計裡, 沒有任何資料可以被刪除, 亦即只要曾經存在, 進入 Fossil SCM 就會被當化石看待.

有時候 Fossil SCM 的這項以化石看待資料的設計, 被許多外部人員批評, 但是若能再更深入使用 Fossil SCM, 就會被許多精巧的設計所吸引, 也能了解只要與時俱進, 以 1989 年的 ANSI C 所寫的軟體, 從來沒有過時的問題.

假如 Python 能夠被稱為 Battery included 的計算機程式語言, 那麼 Fossil SCM 則是自備太陽能發電裝置的精巧分散式版次管理, 因為除了 client 與 server 都是同一個約 9MB 的檔案外, 將套件改版內容放入 Fossil SCM 能夠自給自足, 不需要其他操作系統與第三方工具程式.

至於許多人批評 Fossil SCM 的網際伺服器無法使用 https 網路協定, 但這應該改為 Fossil SCM 無法直接作為 https 網路協定的伺服器, 但是結合 Stunnel 在 Ubuntu 環境就可以配置 https 的網際伺服器.

另外, Fossil SCM 除了獨特的分散式版次管理功能外, 還包括 Chat, Forum, Ticket, Wiki 等網際協同工具, 因此只要一台 Ubuntu 虛擬或實體主機, 加上最新版的 fossil 與 Stunnel, 就可以啟動程式開發服務.

至於在 Windows 環境中, Stunnel 雖然無法直接以 execargs 啟動 Fossil SCM server, 但若分別利用 fossil server 與 Stunnel 的 https 網路代理, 並將 fossil 送出的封包限制在 localhost, 並利用 NSSM 分別設置 fossil server 與 Stunnel 啟動服務, 就能得到與 Ubuntu 上相同功能的 Fossil SCM 網際伺服器.

Fossil SCM 的另外一個精巧設計與使用者密碼的管理有關, 與帳號對應的密碼欄位, 若是 40 字元的 SHA1 hash, 表示經過編碼, 若其字元不足 40 字元, 則視為明碼. 就因為有這樣的設計, Flask 網際程式可以利用 session 存檔記錄從 Oauth2 協定登入的用戶名稱後, 設法從 SQLite 格式的倉儲中設置用戶密碼或使用權限, 取得 SSO (Single Sign-On) 的系統管理流程.

最後, 以 TCL 作為 Scripting 的程式延伸架構, 讓 Fossil SCM 從編譯完成後, 就賦予使用者動態客製表單與功能延伸的諸多彈性, 當使用的層面越廣就越能體會程式設計者的許多巧思.

就只有這樣嗎? 沒, 大家應該知道 Github 之所以受到歡迎, 多少拜 Github Pages 所提供伺服 html 與 Javascript 的專案網站功能, 但 Github Pages 只能伺服最新版本的架構, 碰到 Fossil Documentation 只要提供版次號, 就能夠擷取所有新舊版本靜態網頁的功能, 才 8MB 的單一程式檔, 就能將 Github Pages 遠遠拋在腦後, 想必讓許多人始料卻未及......