所有 openq 开发人员和关心 openq 兄弟们请进来一下。

fundawang

Gaim 2.0.0 至少等到两三个月后才会推出。我个人支持把协议部分剥离，但不赞成单独提出一个libopenq。因为即便是MSN、ICQ这样的协议，Gaim和Kopete也是各自在使用不同的算法来完成同样的功能。

各位大虾可以共同造一个libopenq，但不要把它单独拿出来就行了。也就是说，无论是openq、Eva还是luma，都自带libopenq就行了。

至于数据是否共享，个人认为可以用户选项来设置。

小锁

支持分离开来，lumaqq，eva,open,Kopete公用一个libqq
语言还是用c吧，如果是java的话会影响其通用性
如果需要封装成c++的类库也容易的多libqqplus
这样大家都能专心开发图形界面，避免重复开发。

Awei

支持～

pupilzeng

没有参加开发的人投了票也还是白搭
要是能参与开发的话，就先做起来。

henryouly

呵呵，sunmoon这么快就把计划揭出来了
我还打算搞出来后给个意外惊喜

我对这个问题做过一下更多的思考。包括一些技术实现细节的问题

1. 语言问题。和sunmoon讨论过用c而放弃c++，不过我觉得可以用c来写成类似c++的方式，可以很容易给native c加入对象/继承等oop专有的属性。具体例子可以参考gaim的主干代码，gaim的继承图可以在gaim.sourceforge.net的开发api页面找到
最典型的就是gaim msn协议当中的object.c文件

2. 接口问题，就我熟悉的gaim的plugin接口来说，可以参考ft.c里面，对文件传输的处理。openq的文件传输功能并没有直接用gaim的network io，而是创建好自己的send recv函数后，把fd交给gaim处理。

3. 对象的层次结构图
我在纸上已经有个大概结构，不过懒得用gimp画了，允许我偷偷懒吧。今天是我生日，呵呵。

大家继续讨论吧，其实我已经做了一点点尝试了，主要想先把主要代码框架写出来，然后就可以划分出模块，大家用cvs开发了。

henryouly

最初由 luma 发表
LumaQQ本来也就是一个库，我为此都写了很多文章放到主页上，主要是希望有人感兴趣能够二次开发

我都拜读过你的文章，呵呵，很pf你可以花这么多时间做文档和注释。。。我这人最怕文档，虽然我也知道这种习惯不好。。。

henryouly

最初由 Brain 发表
分离出来确实是明智之举.

另外,能否应该同另外几个qq实现方式多多交流,比如java 实现的luma还有C++实现的eva和kopete插件.
一旦有这么一个独立的QQ库将会方便许多

我是绝对lumaqq的支持者，也和luma大虾私下有不少交流:p
不过我台机太慢了，再开个eclispe更要命，所以还是坚持着openq的开发和偶然更新。
可是能力有限，同时学业也繁重，跟sunmoon一样希望有牛人出来撑场，接过开发任务。

yunfan

是应该分出来， 只是这个工作一直都没有做， 如果有libopenq， 我就不会自己去写libeva， 只用做c++的封装就好。我详细看过，加密，解密，登陆，登出的代码。 只有加密，解密可以重复利用，其他的都和gaim连的太紧了。

我没有看luma 的GUI方面的代码，只研究了有关qq协议的 class， 他的OO 设计很好， 我就基本沿用了他的设计， 个别的地方正在重新设计。

我是openq 和 lumaqq的支持者， 我也很乐于为 openq和lumaqq 写代码， 如果需要，告诉就好了。 我C++写的库，基本快写完了， 那就写完吧，写一半总是不甘心啊。我个人觉得有不同的实现也不错， 可以给其他人更多的启示，希望更多的人参与到开源活动中来。

支持把有关qq协议的部分分离出来， 如果人手不够，我可以加入。

henryouly

赞！欢迎你的加入