数据打包协议

之前写的Crab用了很长一段时间，发现问题越来越多。前一阵一直有一个很强烈的Idea，但是一直没有时间搞，最近终于有一些时间了。

这两天将这个Idea的方方面面都想了n遍，参考了很多framework，逐渐梳理思路。这是一个漫长的过程，费了不少脑细胞。

今天突然PM因为一个线上问题找来，猛然发现自己真的陷进去了，放在项目和产品上的关注度大大减少，这样下去不是办法，得安排好自己的时间。

不知道自己是不是还要放些精力在技术上，不管怎么样，自己有很大的兴趣。Team成员都很Nice，分担了不少具体的工作，把省下来的时间随性的去研究技术，不知道是不是太贪心了。

anyway，既然开头了，就继续做吧，掌握好时间和精力分配就好了。

顺便简单说一下最近的这个Idea：

基于PHP的MVC实际上没有什么特别的，就一个请求的分发定位而已，根据请求中特定的参数，调用特定类中的特定函数，Crab现在就是完成这个简单的工作。

而一些Service模型中，也有类似的分发机制，比如Hession、SOAP、PHPRPC等等，都是通过请求参数来定位到某个类中的某个函数，只不过输入输出的格式不同而已。

我的考虑是，这两种模型完全可以复用一套代码，不需要做任何修改。首先我对输入输出格式进行一下分类，先是输入：

1. $_POST、$_GET、$_REQUEST、$_FILES，以PHP数组形式
2. json、phprpc，基于文本的数据打包协议
3. xmlrpc、soap，基于xml的数据打包协议
4. hessian、mcpack、amf，二进制的数据打包协议

然后是输出：

1. html，一般性的网页
2. json、phprpc，基于文本的数据打包协议
3. xmlrpc、soap，基于xml的数据打包协议
4. hessian、mcpack、amf，二进制的数据打包协议

可以利用一个Parser和一个Renderer组件来对输入输出进行处理，而他们中间执行具体业务逻辑的Action，则无需了解任何细节。并且每个Action都要像普通函数那样，有明确的输入和输出，由一个中央控制器来将输入传递给Action，并将Action的输出传递给Renderer。

除此之外，还考虑了有关Validate、Configuration、Logging等问题，这之中很多都需要中央控制器来协助完成。

最终使用这个framework开发的效果是：只要编写若干小的可复用的功能，如Validator、Action、Renderer等，然后编写配置文件将这些串起来（配置文件期望是XML的，这样我们可以通过扩展Eclipse以一种可视化的方式进行配置），最后交由中央控制器来协调运行。上学的时候用过struts，已经忘记是什么样了，这个Idea跟我印象中的struts有些相似之处。

这里面还有一个非常重要的东西，就是一个PHP的Compiler，因为读取解析配置文件会花费大量的时间，我期望通过Compiler将解析结果直接编译成一个PHP程序，那么之后的请求都不会重新去处理配置文件了。

以上是一些粗略的介绍，欢迎拍砖