那一封公开信似乎是很久以前的事情了。

不过，自那以后，CnPack项目的进展就不是很快。据说是由于主要负责人很忙。可以理解。

随着Delphi 2006的发布，我期待的是全新的CnPack。可是，还是比较慢的。这个我觉得主要是因为Delphi 2006又是Borland IDE的一个革命性的进步（尽管马上就会叫做DevCo IDE了）。

可是，大概还是上次我提出的问题，架构的可扩展性不是很强。

这样的一段时间我也没有闲着。走自己的路嘛，在多次实验之后，SharpBuilderTools的架构已经被我修改的差不多了。现在，我可以说已经开发出了一个比OTA简单一些的“OTA”，叫做LeXDK。文档还没有写完，最后阶段的重构还需要一周左右。但是可以肯定地是这是一个十分灵活，开放的架构。

说他开放，是因为Open Source，基于GPL协议。而灵活，则表现在整体的结构是一个专家系统主框架和若干小专家DLL，随意的扩展DLL的数量就可以让主框架在BDS启动的时候加载不同的功能部件。

相比较CnPack的优势：
1. 每个小专家的设置都是独立的，可以更加灵活的确定是不是加载这个专家。

2. 使用XML文件存取用户数据，而不是读写注册表。

3. 可以用C#/Delphi for .NET/VB.NET/Chrome等等.NET语言进行扩展开发。开发子专家不需要重新编译框架。

4. 可以把BDN上面那一次C#Builder/Delphi 8的OTA比赛的很多项目都做成该框架可以使用的Plus（子专家）。我已经完成了C#Builder Goodies 1.1和AddMany 4.1的修改，证明了这样的架构是可行的。下一步是将其他几个有用的OTA也收进来。

5. 由于可以使用Delphi for .NET来开发这个SDK的Plus，所以，我想CnWizards里面很多专家功能应该也可以导入到这个框架里面。不过仅仅还是理论上的可能，我还没有实验过。

不足则表现在：
1. 由于基于OTA for .NET，仅仅支持BDS系列的IDE（C#Builder，Delphi 8/2005/2006）。

2. 现在仅仅由我一个人开发维护，测试做的明显不够，代码不算很精良，运行效率只怕不是很高。

3. 缺少LeXDK使用方面的文档。我正在利用业余时间做。

这样的一个SDK大约会在4月之前完工。

这个SDK使用了大量的SharpBuilderTools的代码。由于SBT被证明是品质不错的OTA，所以，我想我的SDK还不至于品质恶劣。

敬请期待。;)

“由于基于OTA for .NET，仅仅支持BDS系列的IDE（C#Builder，Delphi 8/2005/2006）。”不支持纯Win32的IDE这个比较遗憾，用Delphi7或更低版本的人还是很多。

是的啊,
至少我不想往上升了,就用7了.

很遗憾，这还用着Delphi7呢

其实我的目的也不是要大家改用D8/2005/2006。而是希望CnPack及早的实现完整的插件架构。

对于我现在做的CBC 2项目，由于LeXDK的出现，已经可以做到框架和插件分离开发，互不影响，甚至可以单独升级插件功能（换一个DLL）而不必重新编译框架。

不过基本上采用的是.NET的反射技术实现的。估计用Delphi的RTTI技术也可以实现，甚至bpl包本身就和.NET Assembly结构类似。估计不是很难实现的。但是现在Delphi领域这样的架构大约只有CodeRush和Castalia做出来了。开源的GExperts和CnPack都没有做的这样彻底，有一点点缺憾。

没有想到仅仅是一个摘要就引起了大家的兴趣。我会在做完LeXDK和CBC 2 WalkPace Final的发布之后尽快完成这一公开信，详细地阐述我最近的一些想法。