初心
我逐渐意识到自己有了一定的编程能力。这种对于编程能力的泛指是说,我其实可以独力写很多代码,自己写一个项目了。我拥有了独力思考的能力,如何去很好地用逻辑去定义一个新的功能。如果能把所有的代码按照统一的逻辑整齐地放置,那么我相当于拥有了架构的能力。其实在编程的世界里,我的能力已经很强大了。那么为什么不用一个项目去证明它呢?
思源湖计划就是在这样的想法下确立的。多年以后,若这个计划有蓬勃发展的一天,那么这个开头想要告诉后来者:计划建立的初心只是一种个人的自我证明,而不是改变世界。
定义
之所以名字取思源湖计划,就是没有特定的要做的功能。不过大致上我希望用活跃户不要太多,差不多几千一万人左右吧,毕竟人多了也买不起服务器。
思源湖是上海交大闵行校区的一个湖的名字。也是一个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解耦。需要再想一想。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。