思源湖计划

初心

我逐渐意识到本身有了必定的编程能力。这种对于编程能力的泛指是说，我其实能够独力写不少代码，本身写一个项目了。我拥有了独力思考的能力，如何去很好地用逻辑去定义一个新的功能。若是能把全部的代码按照统一的逻辑整齐地放置，那么我至关于拥有了架构的能力。其实在编程的世界里，个人能力已经很强大了。那么为何不用一个项目去证实它呢？

思源湖计划就是在这样的想法下确立的。多年之后，若这个计划有蓬勃发展的一天，那么这个开头想要告诉后来者：计划创建的初心只是一种我的的自我证实，而不是改变世界。

定义

之因此名字取思源湖计划，就是没有特定的要作的功能。不过大体上我但愿用活跃户不要太多，差很少几千一万人左右吧，毕竟人多了也买不起服务器。
思源湖是上海交大闵行校区的一个湖的名字。也是一个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解耦。须要再想想。