Bazaar (2004 年從 Gnu arch 分出), BitKeeper, darcs, Git, Mercurial 是目前較為常見的分散式版本管理 (Distributed Version Control Systems, DVCS) 技術, 其中自 1998 年前後推出, 唯一商用閉源的 Bitkeeper, 也終於在 2016.05.09, 宣佈轉為開放原始碼套件: https://users.bitkeeper.org/t/bk-7-2ce-released-2016-05-09/93.
其實, 早在 1995 年左右的 Sun WorkShop TeamWare 就已經擁有分散式版本的相關技術, 而且在許多與機械設計相關的 PDM/PLM 系統中, 也都提供各種分散式版本控管的功能, 只是大多與封閉的檔案系統格式搭配使用, 使得多人協同模式下的電腦輔助機械設計流程, 成本不斷推升, 而且造成導入新技術的步調緩慢.
當然, 這些國際大公司面對快速發展的數位虛擬與雲端技術, 眼看無法透過賣斷的使用授權來限制使用者, 也紛紛隨著許多創新的先行者 (例如: Onshape), 喊出不再販售大而無當的單機賣斷版本套件, 而改採較具彈性的網路訂閱授權.
接下來, 當快速進展的全球協同模式必得讓各方團隊開始自行打造各式本地端、區域網路端、廣域網路端與雲端上的網際服務系統時, 目前最佳的授權認証模式, 則多採取 oauth2 的協定進行, 例如: Onshape 已經釋出 node.js 相容的程式模組: https://github.com/onshape/passport-onshape.
儘管如此, 身為一般的機械設計產品開發團隊, 仍然無法像全球大量持續甩開 Microsoft 約束的程式開發者一樣, 熱烈擁抱諸如 Linux 與 FreeBSD 相關分支, 因為 http://www.freecadweb.org/ 尚未大到可以取代許多封閉套件的地步, 現階段只能期待 Onshape 的授權方案能夠持續友善, 未來能夠有機會藉著清楚展示設計流程的分散式版本管理, 讓使用者能夠從此自混水中解脫.
儘管 Onshape 的 API 使用授權尚未全面釋出, 但是假如希望先利用 oauth2 自行打造一個網際產品設計開發系統, 可以參考下列的簡單程式開發描述:
-
讓使用者以 Gmail 帳號, 經由 google 制式流程登入後轉回應用程式
使用技術: oauth2
-
網際程式可以在本地端、區域網路端與雲端平台上佈署, 得到相同執行結果
使用技術: 利用物件案例的啟始, 建立所需的環境目錄架構, 以及起始資料庫檔案等, 利用操作系統模組讀取特定變數判定執行環境
-
資料庫存取技術與分頁
-
人性化的 Javascript 或 Brython 環境導入
-
美化的 Template 與 css 導入
-
Github, bitbucket 與 gogs 的程式開發版本管理
-
規劃所要維護的資料表:
人員名單含角色管理
事件管理
網際運算 (結合 Jupyter)
參考資料:
flask
http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-now-with-python-3-support
oauth2
https://blog.yorkxin.org/posts/2013/09/30/oauth2-1-introduction/
https://tools.ietf.org/html/rfc6749
git
working flow
https://www.drupal.org/node/803746
Jupyter and oauth2