思源湖计划

初心

我逐渐意识到自己有了一定的编程能力。这种对于编程能力的泛指是说，我其实可以独力写很多代码，自己写一个项目了。我拥有了独力思考的能力，如何去很好地用逻辑去定义一个新的功能。如果能把所有的代码按照统一的逻辑整齐地放置，那么我相当于拥有了架构的能力。其实在编程的世界里，我的能力已经很强大了。那么为什么不用一个项目去证明它呢？

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

定义

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