由于时间有限,开发在天天的上午6点到9点,晚上9点到12点以及周末,因此项目周期可能比正常的要长一点,个人计划以下:html
这个阶段主要针对 zend engine 一些经常使用的数据接口作一些面向对象的封装,好比用的最多的 HashTable, zendAPI 会为其提供一个STL风格的迭代器进行数据访问,常见的 HashTable 的访问语义接口,方面开发者的平常调用, 避免用到类型不安全的宏调用。数据库
这部分主要让开发者方便的往 zend engine 挂载本身定义的函数,变量和类等等,将一些平常的参数获取以及返回值进行标准化,让书写自定义函数的时候只关心本身的业务逻辑,让这部分代码远离 zend engine 底层的细节。在面向对象这一块跟函数的思想也差很少,主要让开发者建立本身的名称空间,自定义的类更加的简明,不用太关心底层一些繁琐的细节, zendAPI 到时候会提供对 PHP 版本号的兼容,因此对之后的升级,可让您的扩展最大限度的避免修改。小程序
PHP 从最开始的时候带入了一些很很差的全局变量和资源,其实这个并非很好,会让程序维护性大大下降。可是历史已经已经没法改变,咱们只能以一种相对比较安全的方式去使用它,慢慢的淘汰它,在 zendAPI 中咱们将对其提供一些统一的访问接口。api
扩展是不能脱离 zend engine 而存在的,咱们必须将咱们开发的扩展挂载到 zend engine 内核上去,zend engine 有本身的一套启动流程,也有本身明确的生命周期的概念并对外提供了不少的钩子函数和大量的宏去帮组咱们完成这个工做,可是相对来讲仍是至关繁琐和复杂的,而咱们有时候并不必定须要陷入这种细节之中浪费咱们的宝贵的开发时间,因此咱们在 zendAPI 中会对这个过程进行一些封装,尽可能去以一种面向对象的方式去简化整个启动过程。安全
我历来都认为,一个好的开源项目,文档这部分很重要,甚至有时候比项目自己还重要,由于如今你们的节奏都比较快,没有时间对研究代码,一个项目若是有好的文档支持,会大大下降入门门槛,让更多的人去使用这个项目,才能让其发挥出价值。若是 zend engine 内核这方面若是作得好的话,估计也没有咱们这个项目了。zendAPI 的文档主要在官网上进行提供,共有三个方面函数
由于是暂时就我一我的开发,包括网站的维护,文档的书写,因此不少方面很欠缺,到这个阶段初版的开发基本结束,我在这个阶段基本是完成打包脚本的优化和一些小工具的开发,好比生成项目结构的小程序。规范化版本号与版本发布流程,针对主流平台进行测试,提供相应的二进制包(rpm, deb)等等。工具
总的来讲,这个对我来讲挑战很是大,不少事情对我来讲都是第一次,但愿 zendAPI 能顺利的跟你们见面,谢谢。测试