思源湖計劃

初心

我逐漸意識到本身有了必定的編程能力。這種對於編程能力的泛指是說，我其實能夠獨力寫不少代碼，本身寫一個項目了。我擁有了獨力思考的能力，如何去很好地用邏輯去定義一個新的功能。若是能把全部的代碼按照統一的邏輯整齊地放置，那麼我至關於擁有了架構的能力。其實在編程的世界裏，個人能力已經很強大了。那麼爲何不用一個項目去證實它呢？

思源湖計劃就是在這樣的想法下確立的。多年之後，若這個計劃有蓬勃發展的一天，那麼這個開頭想要告訴後來者：計劃創建的初心只是一種我的的自我證實，而不是改變世界。

定義

之因此名字取思源湖計劃，就是沒有特定的要作的功能。不過大體上我但願用活躍戶不要太多，差很少幾千一萬人左右吧，畢竟人多了也買不起服務器。
思源湖是上海交大閔行校區的一個湖的名字。也是一個FIREBIRD爲基礎的BBS的名字。因此私心仍是但願用戶以交大相關的爲主。
由於寫JavaScript比較順暢，因此會是個用JavaScript爲主的項目。
命名空間以syh開頭。
但願跟AWS的服務很好的結合。不要由於怕廠商依賴而變得束手束腳。
全部的配置項都以環境變量配置。
但願可以作好先後端的統一與分離。
但願不要半途而廢。
以兩年作一個終結，2017年1月12日回頭再看。

DynamoDB

我對於AWS的這款數據庫一直抱持着奇怪的感受。做爲一款非關係型數據庫它的廠商依賴也太嚴重了吧，只有AWS纔有。不過因爲以前就講過的，思源湖計劃不畏懼對AWS的廠商依賴，因此仍是打算用。另外一個問題是DynamoDB實在是……很差用……簡單地說就是它的應用場景很難想。在對一個數據庫作應用計劃的時候，又須要時刻計劃着配額，實在不是很好的感受……
最近我以爲它應該還蠻適合存session的，能夠說是特別適合session的場景，都不用另配個cache了。可是nodejs的dynamodb的第三方session庫connect-session實在是太廢了……估計會先重寫一下那個庫吧。不過其實不急，由於反正符合標準，用文件系統或者mongodb先代替一下也挺好的。
聽說在EC2上搭個MongoDB會很耗費IO……哎不行的話RDS大概會將就一下。其實我以爲數據庫當中Redis挺好的，不知道爲何最後淪落爲作cache了……

用戶系統

由於但願可以搭載FIREBIRD用戶系統的關係，因此用戶系統最好要本身設計。沒有太多OAuth受權的餘地，可是須要來自不一樣來源的帳號（水源、客棧）的綁定。我以爲drywall項目不錯，可是應該會扔掉一些東西吧。另外是RDS好仍是DynamoDB好也尚未決定……我的傾向於DynamoDB吧……
還有權限啊什麼的也好難搞啊啊啊啊

machine的定義

machine定義爲一個能夠運行syh項目的設備。例如一臺windows主機，一個Raspberry Pi，或者一臺OSX。多個用戶能夠在同一個machine上登陸，可是machine只有一個。machine應該有一些獨立於用戶的控制權概念，例如讀寫文件，讀寫IO等等。一個machine上能夠同時擁有多個進程，多個用戶，可是因爲它們的某些資源是共享的，例如串口、網絡鏈接等等，因此應該有獨立的進程去表明這臺machine，這個進程跟其餘的全部進程都不同，且惟一。
瀏覽器模型中也應該有machine的概念。因爲沙盒的限制，使得來自同一臺主機、不一樣瀏覽器的訪問沒法匹配，因此在瀏覽器中的machine就被定義爲針對瀏覽器的沙盒。
因爲同一瀏覽器的不一樣tab又能夠訪問同一個沙盒，而JavaScript又是單線程的，能夠認爲同一瀏覽器的不一樣tab是不一樣的進程，而同一設備的不一樣瀏覽器（因爲他們不可以訪問互相的資源）是不一樣的machine。以這種觀點來看，容易得出「隱私模式下會開啓新的machine」以及「清空瀏覽器會致使沒法識別原有machine」這樣的結論。
用戶能夠在思源湖登出，從而使另外一個用戶登陸。可是machine不須要作更換，至少應該聽從用戶選擇地保留一部分原有的數據。用戶也能夠在不一樣的machine上登陸。這樣就能夠作好machine和user的解耦。
machine能夠不屬於任何一個用戶，可是出於場景須要，感受仍是應該有一個「主用戶」的概念，即這個machine能夠屬於某個user，同時又被受權可讓另外一些user進行操做。

process的定義

process有一個很重要的問題，在於瀏覽器端沒法爲session（表明某個用戶）和process解耦。須要再想想。