1、A计划：平台版本在v2.1版本基础上进行迁移，逐个模块改造，平台1.0版本，在业务分支3.0版本之前发布，在3.x版本与其他业务版本结合； 
      B计划：平台版本不再单独演进，将现在的平台技术应用到即将发布的3.0版本中。包括插件结构、动态加载、动态激活，3.0版本中的业务模块一律按照插件规范开发。

改变的原因及影响：
      认为3.0版本再迁移到平台上，就是变相的返工，现在强制迁移到平台，可以节约这部分工期。
      现在强制3.0按照平台插件规范开发，在一定程度上会拖缓进度，也是要考虑的。
      在3.0规范中使用的是平台最成熟也是最核心的成果，风险相对较低。
      对平台版本的要求，从原来的Kernal插件化要求，改为业务模块插件化要求。原来最棘手的解耦和和插件化改造，变得不再紧急。这是一个相对成熟的改变，因为Kernal的插件化是在没有必要。                 
      原来位于Kernal范围的功能，部分剥离到业务相关的部分。比如工程管理、数据库，全部改造成注册、通知机制，而不再承担具体的业务。这在很大程度上降低了平台的设计复杂度和业务相关度。我认为，这是本次修改中最有意义的部分。

      新需求的开发中比较棘手的是新业务类型的支持，要求平台不单可以支持预定义的业务类型，还要支持业务类型扩展（也是通过注册机制）。从一定程度上来讲，业务类型注册和模块的动态加载之间是有矛盾的。因为之前的设计思路并不是Eclipse的那种Lazy Load，而是PreLoad。
      如果模块不加载，如何注册业务呢？如果不知道支持了哪些业务，如何知道加载那些模块呢？这中间有一个断档，就是预定义基础上的扩展。我想，还是通过配置文件实现，在原先的插件节点基础上增加一级节点，用于指示业务类型。平台扫描这一级节点，从而确定自己需要支持哪些业务类型，而并不加载。只有在工程打开确实需要那些业务类型的插件才加载，模块加载能否成功，取决于对软件的授权。这样，又识别出一个对象，用于保存业务类型的状态。
      基本业务流程是：业务类型记录对象扫描配置文件->保存配置文件中的业务类型列表到内存中，关闭配置文件。（有一个用于运行时切换工程业务类型参数的界面状态，其中的业务类型是否可用的状态，取决于该类型记录对象的状态。“另外，由于部分业务类型之间是互斥的，所以这部分内容需要写入配置文件中。”——经确认同行的这种互斥做法是没有根据的。）
                                      工程打开->通知Dll Loader->Dll Loader根据工程的业务类型配置，查找内存配置文件，加载、激活对应模块。
                                      工程参数修改->通知Dll Loader->Dll Loader根据工程业务类型，卸载停用模块，加载激活、新增模块。
                                      工程关闭->通知Dll Loader->Dll Loader卸载业务模块。
                       

2、A计划：CCB管理配置文件，规范插件对主界面的配置。
      B计划：必须为界面配置文件准备替代方案，防止因为配置文件损坏造成的程序加载失败。

这部分改造是最不情愿的一部分，配置文件怎么会不可靠呢？是会不可靠，所以要做好两手准备啊。最后被毙掉是因为配置文件保存功能上的一个bug，主要是因为需求不明。毙就毙了，可配置界面的逻辑有点小复杂，很佩服office的设计人员。不可否认，如果有配置文件会带来都少便利，包括那个让我引以为豪的预设-激活机制。
做API和做程序完全两码事，做程序往往会用一些比较巧妙的手段，让变成更轻松。做API的话，过分的巧妙反而会让二次开发的兄弟摸不到头脑，所以更重要的是清晰、良好定义的调用过程。比如，曾经想在界面一次到位地添加一个三级菜单UIConfig->AddMenu("File", "New", "New Filetype1");，这样使用起来倒是方便，但是似乎掩盖了过多的中间过程，比如如果"File"或者"New"不存在等等，需要诸多的解释。
如果分成三步来做，就清晰多了。
int iFileID = UIConfig->AddSubMenu(0, "File");
int iNewID = UIConfig->AddSubMenu(iFileID , "New");
int iNewFT1ID = UIConfig->AddSubMenu(iNewID , "New Filetype1");
再来一个UIConfig->ConfigMenu(iNewFT1ID, ResponceResource);
很清晰，基本不需要解释。写的时候能够多动些脑子，代码行与一次到位地添加相当。

对外清晰、良好的定义，可以有效降低实现的难度，并有助于消除bug，原因是清晰定义的函数边界明确，有利于设计、实现和测试。
界面上元素的相对位置，完全靠内部编码逻辑结构，直接解析出其的位置。
配置文件，可以在后续使用，作为界面调整的依据，比如供最终用户Customize，将是很炫的功能。