不只是Ruby与Java的抉择

面对ROR，又摇摆不定了，我在自己的BLOG上把自己狂骂，但还是无法抉择：
先说一下我要做的事情：
建立一个支持富文本编辑的知识管理系统，你可以想像成Wiki，但不止于此，详细的东西写在BLOG上了：
http://www.eastviking.cn/page/eastviking?entry=%E6%88%91%E6%83%B3%E8%A6%81%E7%9A%84%E4%B8%8D%E6%98%AFwiki_%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3%E5%85%B1%E4%BA%AB%E7%B3%BB%E7%BB%9F

我想如果有一个目标来开始学习总是动力比较足一点，但现在就是遇到了这个问题：到底是ROR还是JAVA，明知陷入无谓的争论只是浪费时间，但还是不能停止去想，所以请各位老大给个主意：
1、JAVA技术浩如烟海，每一项要想搞熟练都不容易，相对来说ROR要简单一点
2、性能方面已经有对照了，暂且不管了，认为经过优化的ROR与JAVA性能相当好了
3、我认为主要的问题：如果是JAVA，我可以参考很多已有的实现，甚至从开源系统中COPY很多现有的功能，使用很多已有的插件。甚至在已有的系统上改造。但ROR下，如果自己搞不定，很难找到参考
主要是第一点与第三点的矛盾让我犹豫，写下这些问题也算是让自己好好分析一下，但这儿老大比较多，期望看到好的建议。[url][/url]

我有类似的想法，我把它叫做“agile-writing”（敏捷写作）。
肯定用RoR做亚……这种全新业务，用Java会累死滴……赶快动手做起来吧，我跟你一起掺合掺合。

我觉得全新的东西是ROR反而会累死的：所有的功能都要重写。
如果用JAVA，拿一个WIKI来分析一下，能用的就用，不能用的就改。。。

最担心的是什么：
我认为现在的WIKI非常弱，是因为对文档格式支持的太差，如果txt文档没问题，图文混排或带表格就完蛋了。
所以我认为差的不是架构或是思想，而是对文档格式的支持。
为了解决这个问题，我看了很久的ODF(openDocument Format)的官方文档，认为可以用这个来解决，但最大的难度在于一个open document的解析及构造器。我也不确定这个东西能不能搞出来，如果搞不出来那估计还不如直接去用mediawiki呢。
我现在有个机会可以拿到路透社的新闻数据格式，但没有寄予太多期望，因为ODF已经足够好了。

赫赫
你这个思路就是错误滴，技术驱动。你为什么要做这个东西？因为要给写作者一个理由去写。为什么他们要写？原本只想写一篇的为什么要写三篇？原本只想写短文的为什么要写长文？原本只是一个稍纵即逝的念头为什么要在几个月的时间里不断地写？原本只是自己的想法为什么变成好多人一起在写？这些问题才是你要去考虑的。什么文档格式，扯淡。作为用户我就是想写东西，我管你是路透社的新闻数据格式还是什么格式？

是的，要让人家去写，那就有个方便不方便的问题。
我是从文档格式方面去考虑的。
现在的WIKI上面不方便搞出复杂的东西，现在的WIKI上的文档是不能下载成WORD的，PDF倒是有很多支持。
既然是知识管理或是文档管理，能进不能出还不是走回Lotus 文件数据库的老路。

格式是后台的东西，用户在前面是看不到的。
使用opendocument只是支持这样的一个标准，因为它是开放的。

其他方面的功能，版本管理、用户协作，这方面的成熟的产品不少。如果用ROR要自己造车了。

解决丰富文档格式的支持问题从来都是wiki的一个难题，和你用什么编程语言是无关的，不管你用Java，ruby还是python，都需要面临这个问题。confluence算是支持的最好的wiki了，但是他的支持仍然没有达到满意的程度。你可以参考一下他的实现。confluence比较大的两个特点：一是render框架做的很强，自定义很强大的macro，还带有rich editor，二是用tonic plugin框架做核心，可以自由动态扩展wiki语法功能，只要你能做出来，它就能支持。

我觉得单纯做wiki，很难超越confluence。对于文档格式支持来说，非常值得借鉴confluence的做法。

另外，所谓的“能用就拿来用，不能用就改”的想法是完全错误的。你与其改一个现成的软件，还不如自己开发一个成本来的小，像confluence这种大型软件，你光研究清楚它，就已经很不容易了。

如果考虑保留文档格式。
大部分的Blog (我用过的 blogjava, csdn blog, blogdriver, i170) 都支持格式复制。
GMail也支持，能够保留Word Format。

要说具体实现，一定有很多人说。
Online Editor。Html Area,  FCKEditor等。

我也不知道为什么现有的Wiki就是不支持格式。
（Robbin说了，confluence支持rich editor。）

也许所有的遗留系统都有这种傲慢的习惯。比如，phpbb。:D
只支持自己定义的一点格式化写法。

所以，格式问题不大。可以采用现有的方案。
Open Doc Format 以后支持也行。

blog现有的功能，我也很不满意。
基本的用户需求，自己的home page指定显示那几篇文章都不行。
就是傲慢地傻乎乎地给你时间排序。连以前的personal home page都不如。
wiki也是。

我也在做这方面的改进工作。不过还是用java。综合衡量，对我来说，对于这样大小的一个系统，熟悉另一种语言和开发环境的代价，和ruby语法的效率提高，基本上平衡。所以，对我来说，用java, ruby都差不多。

----
3、文档创建人如果想从自己的努力中获利是不可能的

关于这个有什么想法？稿费？技术服务支持？

现在人气blog一样很值钱。gigix的blog至少值50万（好像还是一两年前的估值，现在应该长了）

这个我已经想过了。对于大部分人，他们只有一个粗略的点子，只写出零散的三言两语，至多一个短文，就没有后续了。实际上好的点子很多，很多点子可以延伸下去，变成文章、系列文章、教程、图书、开源项目、产品、咨询业务……但是绝大多数人第一没有这个时间和精力，更重要的是没有这个“延伸”的能力。时间和精力的问题很容易解决，因为只要开始了延伸，价值就会逐渐体现出来，那么他也会有兴趣投入更多时间和精力。
所以我的考虑是一种媒体模式。这种模式的特点体现在两方面。第一，它允许写作者从最简单的方式入手，引导他逐渐精化自己的点子；第二，它把写作变成一个迭代的过程，在任意时间点都产出最有价值的作品，而不是要等到成为一篇文章之后才产出价值。做这个东西最重要的考虑是这种媒体模式，只要模式摸清楚了，怎么实现、用什么文档结构，完全是细枝末节的小问题。
楼主能不能把你那个blog链接弄一弄，帖子的版式都被破坏了。

wiki是阐发思想片断、记录灵感并引起他人共鸣的地方

如果被格式阻碍，wiki就根本不是wiki了

看看wiki的老祖宗，就思想交流和参与程度来说，很少有网站在自己的领域内能够和c2.com相提并论

roller这个烂东西，提供了5种编辑器，但没有一种可以让格式规矩一点的，行矩特别大，搞起来麻烦死，只适合洋鬼子写英文。我还是把我的想法写在这下面：

一、不是BLOG -----我要的是一个能够集广泛力量的系统
二、不是wiki -----这种系统太简单了：编辑器不够强大，无法从已有文档生成页面；权限系统不够强大，和需求有很大差距；版本控制功能不够强大

系统应该建成一个知识共享站点：
1、现在的技术文档多以论坛、BLOG等方式存在，缺点是文档创建人无法保证持续性的更新
2、文档创建人无法创建一系列专题类型的文档
3、文档创建人如果想从自己的努力中获利是不可能的
4、阅读人没有可靠的途径联系人文档创建人，从而获取支持或交流
5、除了论坛上，文档阅读人的意见无法反馈到创建人，但论坛的文档管理是最差的，容易沉底
6、现在的论坛或者BLOG、WIKI客户端编辑功能非常薄弱，如果创建人需要从现有文档：最多情况下是从Word中复制，格式是很难保留的
7、现在文档多种格式存在，难以下载为用户需要的格式：pdf被比较多的站点支持，但一个基于开放标准的文档格式：openDocument应该是最重要的需求