Fwd: 我觉得esm还不是特帅
戴楠
amulet-...@googlegroups.com，
另建googlegroup论坛 http://groups.google.com/group/amulet-project
可以从主页 http://code.google.com/p/amulet/ 点连接过去
D13
---------- 已转发邮件 ----------
发件人： eSX <nay...@gmail.com>
日期： 2011年6月30日 上午3:20
主题： 我觉得esm还不是特帅
收件人： 张烁 <avin...@gmail.com>
抄送： 戴楠 <dain...@gmail.com>, 房东雨 <dfa...@gmail.com>, 赵鹏城 <macz...@gmail.com>
我觉得有几点可以再整一下：
1. 代码注释，最好多点，要不不好读。
2. 有了ESM，有限自动状态机的难点在设计状态表，状态表的设计可以考虑再简化一下，否则也不好读。
3. 标准的状态元素是M=(K,E,T,S,Z)，K是状态集合，E是字母表，T是转换函数，就是对应的当状态发生改变时K x E ->K
的过程，也就是说状态变更函数，
S是初始状态，Z是终止状态（集合）。S和Z都是K的子集。这种状态机是标准的编译原理状态机。基本上只能对字符产生作用，主要还是用于词法分析。JSON就很适合。
你可以考虑把输入字符集E变成事件“事件”，因为一个通用的状态机，面对的可不一定是字符，可能是一个动作的产生，譬如说：“网络连接上了”这就是一个事件，而不是一个字符。
相应的，也可以在状态变化时加入对事件的“动作”和“处理函数”，这类似于你esm_perform之后的swtich。
这样，在编写状态表的时候，至少可以增加一个对应的处理函数。
另外对range和exclude range和enum和exclude enum的设置我觉得也可以更优雅一些。
另外，csf的monitor的http状态我觉得还有一些问题，应该仅仅是针对http协议本身进行分析就是一套状态机，剩下的对GET之类的处理，则不需要状态机。
而第一套状态机应该是相当简单的，主要就是针对\r\n之类的状态处理。
赶紧整吧！
BTW，谁建一个关于amulet的googlegroup？方便发邮件？
--
eSX