免费开源的博客引擎，论坛系统，网站模板和轻量级的 CMS

周末有空折腾一下～感谢开源～

感谢开源，顺便问一下为什么进了你的页面后，整个界面颜色变了？

@shihty5

由于原来使用的主题版本过旧（基于bootstrap, version 2.3），且经过较长时间修改代码比较混乱，而且有很多自用内容（邮件列表，Share, Tracking Code等）。所以基于Foundation重做了一套前端主题（Theme），并更换了文本编辑器，体积更小，页面更简洁。套主题使用同一套后端代码（只有配置文件不同），目前为Beta版，可能会有些问题。

感谢楼主开源

@newghost 感觉是他想问V2的黑色背景=。= 不知道理解的对不对

@shihty5 节点的背景

感谢开源
watching

英文版的

@reeco
@pyshift

Thank you， 理解有误

@570k

己在项目主页加入中文版支持链接

请问lz这个如何部署？有没有相关的教程

为啥要在实现一个webserver,和express比较有啥不同哦？感觉有点像是重复造轮子

我说的是WebSvr

@seadir

文档正在整理中，请查看项目中的 “中文支持”

@halfblood

确实造了个轮子

WebSvr 是两年多以前在上家公司时做的一个小项目，当时只是做一个静态的Web Server，后来越做功能越多。

基于它只要是个人比较熟悉，有什么特殊要求直接改底层就可以了。

感谢开源
前两天在cNode 就看到啦。
找时间学习下

看了一下svr/root.js，添删评论的时候貌似还没有考虑到共时操作，有什么简单的解决方法吗？

@jakwings

node.js 是单线程异步模型，

设计思想是首先会更新内存并立即返回，然后同步到文件系统（在一段时间内同步一次，如2秒）,

应该不会出现互斥的问题。

@viaNull

感谢，欢迎测试

全部放缓存数据量大了会不会炸裂？

@towser

曾经也有一些人样问过，经过一段时间实践和测算应该不会。


1) JSON 数据并不会占用多少内存，我测试过一个网站，平均每天发贴1篇，回贴N篇（目前己有450+贴），内存消耗量比布暑初期并没有多占用多少内存（目前仍< 90Mb）。照这个趋势，保守估计1G内存最少可以使用10年。

2) 因为node.js的异步模型，内存消耗基本跟访问量无关，没有线程去消耗内存资源，我通过google analytics在测试网站上看到100~200人同时在线时的线程消耗内存量与闲时访问量并没有多大差别。

3) Node Javascript V8可能单个线程有内存限制，如果流量和规模真的达到这个限制，可能会采取多进程来处理这个问题。但是现在离遇到这个问题还很遥远。

感谢楼主分享，请问这个项目到今天为止做了多久

@rentaro

ourjs从去年开始，最初版本用了两周，10月份上线测试，在运行中不断调整，平均每周大概会花几个小时维护升级，最近一个月升级和整理代码花费的时间比较多。

websvr 是很早的一个项目，有很长一段时间没有维护，ourjs开始以后开始跟着一起修改。

@newghost 啊，我都忘了是单线程的了。可是Node.js的disk IO 并不是单线程的，无法保证回调函数的执行顺序。

@jakwings 啊，我貌似说错了，貌似Disk IO也是单线程的。只是 fs.writeFile回调顺序不知道是否确定……

@jakwings

应该所有的io操作都是阻塞的。

增删改操作会等数据IO，完成以后执行，下一步就是直接跳转或者是关闭请求，这里的回调顺序应该没有什么影响。而且实际上线时也并没有遇到执行顺序问题。

adapter.update(article._id, 'article', article, function(result) {
//After update merge other fields from the old article
utility.merge(article, Articles.all[article._id]);
Articles.update(article);
redirect(); //跳转url
});


你说的那种情况应该是两个有同时编辑一篇文章，一个人先保存，一个人后保存，然后后来的会把前面的覆盖的，但是应该所有的BLOG系统都有这个问题。

@newghost 蛮好。给赞。

@shihty5 节点主题

@newghost 你不是说这可以做论坛系统么，假如一篇文章太热，很多人在回复同一篇文章，这个问题应该会很常见吧……
还是模仿关系型数据库为每篇文章开一个collection收集独立的评论内容比较稳妥。

@jakwings

你说的这种问题还没有考虑过，如果遇到的话应该也可以解决，会优化一下，评论成功时将此评论 push 入 cache array 而不更新整个reply array。 q

最初也想过你说的这种方案，后来考虑到增加一种collection的话开销会比较大。因为评论的有时侯可能会非常随意，导致数量会特别多，评论又都特别短，信息量不大，这套系统又是要兼容文件系统的，每条评论存成一个文件会造成比较大资源开销，初始化的时侯每条评论都要载入内存的，然后进分类，在网站内容多了以后，这个过程可能会比较长。 所以权衡了下采用了比较简单的方案，把评论与article内容都存在一个json文件里。