不是吧，和我视频:shock:
视频这个东西目前在linux系统中，我觉得还不是很现实。 因为现在linux下的摄像头的驱动都还是问题， 视频怕还得再等一两年吧。
为什么不考虑写个QQ的jabber网关，让jabber支持QQ，就像jabber支持msn一样？
再写个好点的jabber客户端。现在的jabber客户端没一个令我满意的（在windows上）。
现在im的概念已经不再是单纯的即时通信了……所以需要考虑以后即时通信以外的那些东西……
如果按照这里提出的想法，你必须想办法让你的服务器直接和腾讯的服务器通讯，而通讯的内容就是交换用户资料，腾讯不会允许你这么做的。这个还不光是涉及到协议是否开放或者是不是赚钱的问题。一般认为，用户的资料是属于服务商和用户共同所有的。即便用户愿意将自己的资料开放给其它服务商，现在的服务商也不一定愿意。
你们可以看看MyIM的下场，他们想通过自己强兼容的优势(当然他们也在很大程度上借鉴了gaim的代码)发展自己的用户群，结果群起而攻之。
晕……为什么服务器间要交换用户资料呢？我觉得主要就是两种情况：eva客户端到某个eva服务器上去查找用户资料，还有就是eva客户端到qq服务器上查找用户资料，而如果要和qq用户通信，那么使用eva时肯定要用一个qq帐号登录的，这样的话别的qq用户要查找自己的资料也只是像平常那样到qq服务器上查找而已，仍然与eva服务器无关。
我对你们想法的理解是，做一个独立的客户端和一个独立的服务器端，而客户端和服务器端使用的是QQ的协议。作为客户端，你可以选择登录到腾讯服务器，这样登录的是QQ号；如果登录到Eva服务器，那么登录的就是Eva号。
这样实际的做法就是在腾讯的协议基础上进行二次开发，而搞出一个和腾讯不完全兼容的东西来。
首先，这种二次开发是完全没有法律基础的。不要跟我说什么大道理，这个那个我不管。我只知道，如果这个东西做出来并投入使用，腾讯会马上起诉开发者。至于是盗取商业机密还是不正当竞争，这个要看腾讯法律部的心情好坏了。
其次，你认为这个东西会有人用么？一个和腾讯不完全兼容的东西，还有自己的服务器，而服务器和腾讯又没有一点关系，实际上就是一个全新的东西。即便没有法律问题，会有多少人来用？腾讯捡到了IM发展用户的最佳时机，但现在潮头已经过去了。UC、POPO统统败下阵来，如果没有操作系统的捆绑，MSN也不知道何年何月才被国人接受。
楼上的还是没有理解对我的意思 8)
如果登录qq，就是现在的eva，有法律问题么？有人用么？如果有法律问题，那现在的eva就该停止。如果登录eva，客户端是兼容现在的eva的，客户端能解析出登录类型，比如我有qq，登录eva的同时连上qq的server，我之前对于自己的想法还是有很多矛盾的地方的，因为想法刚出来，总是不断的推翻先前的某些东西，但我现在正在写一个设计简介，一会儿传上来，大家看一下，看看我说的有没有道理，最近想了很多关于sjinny说的服务器的问题，我觉得可行，稍等...
还有我们的eva细分起来应该是eva+qq，qq就相当于现在的eva，是部分使用qq的协议，而eva则不用qq的协议
还有我们的eva细分起来应该是eva+qq，qq就相当于现在的eva，是部分使用qq的协议，而eva则不用qq的协议
我明白你的意思
你的这个想法，其实就是实现了自己的一个协议，但是这个的可行性，是很值得商量的，因为以前linuxfans有个myIM，你大概不知道，参考一下
按照你的这个想法，其实完全可以做成一个gaim/kopete的一个插件。
因为现在的gaim已经有qq插件了，然后，你再增加一个eva插件。
这样做，跟你说的可能有一点不同，就是用户得登录两个号码，一个是qq号，一个是eva号，但是这些通讯却是可以同时进行了的，就如你所说的:qq的好友一块，eva的好友一块。
如果真要完全实现你所说的那样，使用一个号码登录qq跟eva，我想也不是不可能的，只要把这两个协议的插件综合在一块，然后再加一个判断就可以了
所以，最大的问题:现在已经有这么多存在的im协议，再自己重新开发一个，是否必要，是否可行
楼上的说的也不是没有道理，但注意我的重点，我们的重点不是eva能连多少IM，而是多媒体，我们未必要完全从零开始，重新开发，我说过了，有值得借鉴的都要借鉴，能否给个邮箱，本人将自己的感想发给你 :lol: ，我们在理解上还是有些出入...
新eva设计简介
最近一直在思考eva的未来，通过在linuxfans上发帖子也收到了很多大家的想法，对我影响很大，首先要感谢支持我和向我提出质疑与批评的人。我经过仔细斟酌，考虑了大家对新eva的种种提问和顾虑，现将我对新eva的具体设计写出来，一是为了给自己一个总结，二是为了更好的向大家解释我的想法，第三也是最重要的就是继续接受大家的批评以便更好的做出改进。
一 eva为什么要改变？
这是我提出新eva的原因。yunfan和各位linuxfans开发的eva到了0.3，一直都很不错，大家经历了很多成功与失败，期间无数次的调试最终产生了现在的eva。有了eva，我们在linux平台上多了一个很好用的工具可以和以前的qq好友聊天。可是展望eva的未来，不禁让人顾虑重重。
首先，是eva的法律问题，eva是通过破解qq的协议和qq通讯的，我不是学法律的，我学的是通信，但这一点可能首先就是有问题的，这是根基，也就是说eva的生死是掌握在腾讯手里的，腾讯心情好一天，eva就多活一天，而腾讯如果心情不好了，eva立马就得挂。
第二，eva的功能问题，还是那个原因，eva是通过破解qq的协议和qq通讯的，功能限制非常多，虽然大部分实用的功能均已被破解，但复杂的多媒体通讯，linux平台上同样是需要的，破解是走不通的，难度太大，而且就算大家付出巨大的努力破解了大部分功能，腾讯只要修改协议，加强协议的加密（说不定腾讯的qq2006就已经在酝酿，也许明年你的eva就不能登录了），eva一样会前功尽弃，以后再开发，更是难上加难，何况腾讯还握着一张王牌──法律。
综合以上两条，eva在未来，是必须要改变的，不解决第一个问题，eva是危险的，不解决第二个问题，eva很难长久的存在，改是一定要改，可是我们不能完全放弃现在的成果重新开发，我们该怎么改变，这是我下面的考虑。
二 我对eva未来的想法
先附上我对eva的构想的设计图，其中包含了所有登录方式和聊天方式，我下面将一一介绍。
对于A，他有一个qq号，同时他申请了一个eva帐号[email protected]。在客户端建立个人信息，他将qq号和该eva帐号关联。于是他登录eva，客户端解析出有两个帐号，且eva帐号是[email protected],于是启动eva中的eva_e模块登录eva server中的@linuxfans.org，同时启动eva_q模块登录QQ server。而对于最终面向用户的界面只有一个窗口，只是将好友分成了eva好友和qq好友。
对于B，他只有一个eva帐号[email protected]，这个不用多说，他的eva客户端解析出只有eva帐号，于是只启动eva_e模块登录eva server的@linuxsir.org。
对于E，他只有qq号，于是我们的eva客户端解析出只有qq号码，启动eva_q模块登录QQ server。
所有的QQ client自然是都登录到QQ server。
到这里，登录完成，可能有的人会觉得和gaim很像，的确很像，但你仔细思考一下就会发现其中的分别，我们的eva有server，这很重要，有了server，我们才能自由的发展各种多媒体通讯，否则是不可能的，就像gaim，虽然能用gaim登录很多种IM，只要有插件，但永远都是简单的文本传输，这不能满足linux使用者的需求。有一个现实是我们必须面对的，那就是，只要腾讯不给我们协议，我们永远没法和qq真正实现多媒体通讯。既然只能和qq进行简单的通讯，我们为什么不在保留和qq的简单通讯前提下开发另一个协议公开的多媒体通讯软件呢？现在linux下有吗？我还不知道，可能就是有也是太独立了，没有客户吧，可是看看我们的新eva，你完全可以把他当现在的eva使用啊，怎么会没人用呢？
kopete和gaim倒是很像，不多赘述，我们再来看看jabber，其实并不实用。首先，他能登录那么多IM确实很好，可是我们有那么多帐号么？对于某一个具体的人来说，只不过把他当msn或qq或icq或yahoo message的某一个来用而已，可他依然没有解决linux用户对多媒体通讯的需求，原因，没有server。
eva未来要走有server的路，通过eva，我们所有linux用户可以有多媒体通讯，而同时，在不需要额外开其它软件的情况下可以和qq好友享受现在达到的聊天质量，我觉得客户是不会丢的。
下面，在完成登录后，我来解释一下我设想的聊天过程。
1.A发消息到B
客户端分辨出是发往eva的，在A的好友里有B的联系信息是[email protected]，通过eva_e模块，A的消息到了服务器@linuxfans.org，服务器当然能根据B的联系信息发到@linuxsir.org，@linuxsir.org再发到B。
2.A发消息到C
同样客户端分辨是发往eva的，消息到了@linuxfans.org服务器根据C的联系信息知道是本地服务器，然后发到C。
3.A发消息到QQ
客户端分辨出消息是发往QQ的，通过eva_q模块将消息发往QQ server。
4.A和B视频或语音或传送文件
A发送请求给B，经过和B发消息类似的方式请求到达B，同时将A的IP给B，B同意，同意也经过和消息类似的途径到达A，同时A活得B的IP，于是A和B之间建立了一条临时的通道，进行数据的传递，一旦任何一方终止，该通道解除。
5.A和C视频或语音或传送文件
和于B的方式是一样的，只是请求和同意都在本地服务器传递而已。
6.A和QQ视频或语音或传送文件
不可能，现在没有一个软件可以的，原因就是我们没有协议，腾讯不同意，就算我们破解了也没有用，腾讯一可以法律上起诉你，二可以修改协议。
关于法律问题我谈谈我的看法，有一点是肯定的，不管你采用何种方式，只要没有腾讯的授权，任何软件和qq通讯都是违法的，所以新eva面临的法律问题不是唯一的。而新eva由于大部分模块和qq无关，所以即使面临法律问题也只是部分模块的问题。解决法律问题的途径就是，要么腾讯授权，要么我们放弃qq。两者都不可能，所以不管是什么聊天软件，凡是和qq有通讯的，都是有法律问题的。
三 服务器的问题
从大家的回贴来看，最大的问题可能就是服务器的问题。我之前也很困惑，觉得很难解决这个问题，可是在sjinny的启发下，我思考了很多，最终的服务器形式就是如图所示的。我对服务器这一块不是很精通，但我知道这个问题是可以解决的，我暂且鲁莽的称之为“分布式服务器架构”，不对之处希望得到大家的指教。下面我来解释一下我设想的分布式服务器架构。
最简单的是有两个服务器的情况，比如linuxfans.org和linuxsir.org。A在linuxfans申请的帐号，资料自然是保存在linuxfans的服务器上，而B是在linuxsir申请的帐号，资料保存在linuxsir的服务器上。
首先A登录到linuxfans，服务器验证，再根据A的好友名单，检查在线好友，假设B在线，首先检查本地服务器好友名单，发现@linuxfans.org的只有一个ID为C的，于是检查C的状态，离线，再检查@linuxsir.org的名单，其实就是发送检查B和D的请求到linuxsir.org，有B和D两个ID，其中D离线，B在线，于是linuxsir.org告诉linuxfans.org，linuxfans.org在回发登录成功的信息的同时发送B的在线信号，于是A客户端B亮。至于E，和QQ同样处理，不需要我们介入。登录成功后，客户端会定时向服务端发出检查在线好友的请求，客户就可以动态的看到自己的在线好友。
我们可以看到，服务器之间是不需要太多的协调的，服务器之间基本独立，很像邮件l服务器，各个服务器接到消息传递要求时，由于客户的帐号本身就包含服务器名+ID，寻找并不困难。大家想想邮件是如何在各个服务器之间传送的就能明白这个道理，我们不能局限于QQ的服务器形式。
四 可行性分析
（1）软件
软件分客户端和服务端，客户端应该问题不大，我们有现有的eva，很多东西只是做一个二次开发，我们还有很多现有的聊天软件可供参考，很多东西都不用我们从零开始，最大的问题可能是我们没有做过服务端的开发，我们现有的开发都是连到其它服务器上，所以这一块需要认真斟酌，因为服务端不象客户端，服务端必须要认真设计反复测试，确保非常稳定后才能上服务器，否则将来如果频繁出问题，客户群会迅速减少，稳定是第一位的。所以，该系统的第一个障碍就是服务端的开发
<1>客户端
客户端包括解析模块，eva_e模块和eva_q模块，解析模块负责将用户的登录信息整理和解析。分析出是eva帐号还是qq帐号或者是两个都有，如果是eva帐号，还要搜索如果该eva有和qq关联，就将qq资料调出，启动eva_e登录eva server，同时启动eva_q模块登录qq。这样对于eva用户来说，他只是登录了eva，而他的eva好友和qq好友都能出现在聊天窗口里。提到聊天窗口，主要是对两个不同的好友群提供的功能是不同的，如果和qq好友聊天，那么就是现在的eva，功能不用我说了。如果和eva好友聊天，就有视频，语音...
<2>服务端
服务端的运行方式类似于邮件服务器。
（2）硬件
相对于软件来说，硬件是更难的，硬件的代价是昂贵的，该系统形成的第二个障碍就是寻求硬件支持。
但难并不表示不可行，我提出我的初步设想。
<1>sjinny提出的分布式可以考虑，各主要linux网站联合架设，为什么是可行的呢？因为各骨干linux网站基本上就锁定了相对固定的linux用户，比如我基本上的最多的就是linuxfans，而我同学更多的是在linuxsir看帖子，这样服务器的承载量是可以估计的，如果分析出大概的承载量各服务器可以承载的话，就可以上了。
<2>寻求其它支持，可以和国内有实力的企业谈，甚至可以和腾讯谈，在各自原则不变的前提下尽量达成一个共识，这一块很难，可是可能更有效。
2.系统维持的可行性，客户群（设计上要留住现有的eva用户）
软件存在的一个很重要的因素就是要有一个相对较大且稳定的客户群。首先要留住所有现在使用eva的用户，这不难，因为我们的新eva可以和现在的eva一样使用，对客户来说没有区别，仅仅登录qq，聊天。还有一个潜在的用户群是越来越多的linux用户，他们很多都是windows转过来的，很多都有qq号，即使只当现在的eva使用，eva的客户群不会减少，这是保证。然后如果用户注册eva帐号的话，首先登录并不麻烦，只登录eva就行了，和只登录qq是一样的，但能享受高质量的通讯，用户会考虑注册的，只要我们设计的方便和人性化。
综上所述，客户群其实就是保住现有qq客户，逐步方便的转为eva用户
3.发行
和magic linux一起发行，可以是现eva的一个新的版本，比如0.4，界面更漂亮，功能更多，使用更方便，客户不是问题。
4.总结
该系统有两大障碍，服务端的开发和寻求硬件支持，并非不可克服但难度相当大，欢迎大家提出更好的解决方案
五 问题回复
1.这样的软件以前已经有过了。。。只是没有用户群，这样的软件很难维持
回复：恩，用户不多也是个问题，可是毕竟现在和以前不同了啊，linux正在普及，我们学校就有好多人都用linux了，看看各个大学的bbs就知道了，用户是在不断增长的，用户多了，这样的软件应该是可以存在的，而且是很有需求的，因为我们提供多媒体通讯。
2.这样的软件不是没有，而是很多，只怪你们孤陋寡闻。不过大多发展缓慢，甚至走入穷途末路，销声匿迹。原因很多，最根本一点，就在于不能融入主流商业软件市场。恰恰是要自给自足，自成体系导致这些软件走入死胡同，这种想法本身就是 linux 新手的不切实际的幼稚想法。孤立的产品很难有生存空间，因为市场、用户已经被瓜分干净了。不仅是即时通讯，其他软件也是一样。有无新的功能已经不重要，新的功能并不能动摇老用户对原有产品的忠诚，因为对他们而言 qq 已经足够了，连功能更加出色、完全免费的 uc 都无法和它竞争，更何况那些“半成品”级的产品。你们这样只能是空想，永远都是“如果有这、如果有那......”现在 kopete、gaim、eva 它们走的道路是正确的，只有“拥抱并扩展”才能使你夺取市场和用户，用户是不会使用一个和自己使用的产品不兼容、功能不匹配的产品的，因为那意味着损失，不仅仅是物质上的，还有精神上的，哪怕学习新产品的使用都是一种痛苦，没有十足的必要，人是会选择偷懒的，这就是人们的心理。程序员似乎永远都是和终端用户脱节的。
回复：我不是说自成系统和现有的通讯软件脱节，完全重新设计，以eva为例，按我的假设，eva应该是这样的，保持现在的功能，能和qq通讯，但那些还没有实现的功能就不用去破解了，保持现有模块不减，开发eva之间的通讯，不经过腾讯的服务器，这样，eva之间可以实现复杂的通讯，而eva与qq之间就保留比较简单的通讯，这样不会脱离用户群，原有的用户继续使用eva，而又不断完善eva之间的通讯，我觉得是可以实现的啊，如果认真开发的话，呵呵，欢迎指教...
3.jabber 不好吗？或者其他的开源的IM协议？为什么那么热衷于重新发明轮子？ 当然了，如果你研究过现有的开源IM协议，并且觉得都不符合要求的话，再发明一种新轮子也不迟
回复：如果仅仅是文本通讯，jabber的作用不是很大，对于某个人来说，最多使用的IM估计就一两个吧，虽然我们都有很多的帐号，我们开发eva，对于qq这一块，如果只要达到jabber的这样的效果，早就可以停止了，可是我们还在努力，为了什么？不就是为了使eva用户能像qq用户一样享受高质量的通讯么？所以我说的eva，保持和其它通讯软件的通讯是简单实用的，而eva之间，我们同样可以有多媒体通讯啊
我们未必要重新发明轮子，我们可以借鉴所有的IM啊，但现在所有的IM都不是我设想的那种，当然或多或少某些地方是和我设想的差不多，但都不完善，我们可以继承加开发，整合并开发出一个更完备的IM，开源的目的不正在这里么，呵呵
4.it seems to me that you are trying to implement something just like kopete/gaim
回复：不是gaim，gaim只是把各个通讯软件整合在一起，gaim本身不是通讯软件，而且你要预先设定好所有的帐号再一一登录，各通讯软件之间逻辑上是孤立的，而我设想的eva本身是个linux平台上的通讯软件，打个比方，就是相当于一个完整的qq，包括服务器都有，我们有完善的多媒体通讯，注意是多媒体，任何其它的通讯软件包括gaim都没有。我们保留和其它通讯软件的一个简单实用的接口，qq用户不用申请帐号也能使用，结果就是现在的eva，也就相当于gaim，而如果申请一个eva帐号，那登录的就是eva服务器和qq服务器，能和所有eva有多媒体通讯
5.把jabber进行扩展就行了，因为jabber本身就是通过xmlrpc来调用的。jabber已经可以做msn的代理，没有道理不能做qq的代理。
回复：还是那句话，没有腾讯的授权，不可能真正实现和qq的多媒体通讯，jabber没法代理，就算能连，也是在没有授权的情况下，和其它软件一样，面临法律问题，新eva也有，但这是没办法，我们的重点不是你的软件能连多少不同的IM，而是多媒体通讯，linux平台的通讯软件，没有服务器，多媒体现在还不能实现
6.视频这个东西目前在linux系统中，我觉得还不是很现实。 因为现在linux下的摄像头的驱动都还是问题， 视频怕还得再等一两年吧。
回复：是的，摄像头的驱动是个问题，可是仅仅是摄像头么？很多硬件都有这个问题，我们也许可以空着这个模块以后做，但linux一定要有多媒体通讯，能做多少是多少，linux也正在努力中，驱动问题不会永远存在的...
7.我对你们想法的理解是，做一个独立的客户端和一个独立的服务器端，而客户端和服务器端使用的是QQ的协议。作为客户端，你可以选择登录到腾讯服务器，这样登录的是QQ号；如果登录到Eva服务器，那么登录的就是Eva号。
这样实际的做法就是在腾讯的协议基础上进行二次开发，而搞出一个和腾讯不完全兼容的东西来。
首先，这种二次开发是完全没有法律基础的。不要跟我说什么大道理，这个那个我不管。我只知道，如果这个东西做出来并投入使用，腾讯会马上起诉开发者。至于是盗取商业机密还是不正当竞争，这个要看腾讯法律部的心情好坏了。
其次，你认为这个东西会有人用么？一个和腾讯不完全兼容的东西，还有自己的服务器，而服务器和腾讯又没有一点关系，实际上就是一个全新的东西。即便没有法律问题，会有多少人来用？腾讯捡到了IM发展用户的最佳时机，但现在潮头已经过去了。UC、POPO统统败下阵来，如果没有操作系统的捆绑，MSN也不知道何年何月才被国人接受。
回复：首先我们不用qq的协议，但我们的eva_q模块部分使用，所谓法律基础，所有和qq通讯的软件除腾讯自己开发的都没有法律基础，腾讯会不会起诉我不知道，但我们的软件只有一个模块就是现在的eva是通过破解腾讯的协议实现的，要起诉，现在就该起诉，而且是所有能连qq的通讯软件，看过我的图就知道了，我们的服务器和腾讯没有丝毫的关系，只是我的客户端集成了老eva。如何起诉？会不会有人用可以看我看的可行性分析里的客户部分。
六 简单的写了一点，欢迎大家提出诚恳的批评和提出各种建议。
楼上，把你的想法发在这里好了， 这样大家都可以看到，思索。:)
就是上文了，图也上传了，有兴趣就随便看看吧，有一部分是总结的过去的想法，也有一些修正，还有一些新的想法，总之是完整的解释我说的eva的
按照你所说的，实际上是两个完全不同的协议捆绑在同一个客户端，这个功能Kopete和jabber都已经有了，和Windows中的MyIM也差不多。如果将Kopete与kontact和kaddressbook集成，那么它可以将不同协议的联系人打乱重组，重新按照联系人分组；对于同一个联系人，可以通过不同的IM协议与之沟通。jabber的也比较类似。
至于所谓的eva协议，我觉得和jabber没有什么本质上的区别。jabber本身就是可以进行丰富扩展的，而且它还相当安全。你在它上面搞多媒体的二次开发，比从头发明一个eva协议要省事得多。况且，目前的多媒体通讯一般都是点对点的，经过服务器的多媒体通讯一般都是要付费的，因为没有任何服务器可以承受路由多媒体通讯这么大的流量。
如果eva对QQ的分析仅仅停留在对协议进行分析，模拟一个客户端的阶段，腾讯是不会管的，它不会为了这件事起诉谁。但如果你凭借QQ的用户资源另外发展出一个Eva(至于Eva使用什么协议并不重要)，这个就涉及到盗窃商业机密或者不正当竞争，尽管这件事可能是用户自愿的。
另外，我并非是泼冷水，你认为eva能够发展出什么革命性的多媒体通讯功能么？语聊比得过Skype么？视频比得过gnomemeeting么？
1.A发消息到B
客户端分辨出是发往eva的，在A的好友里有B的联系信息是[email protected]，通过eva_e模块，A的消息到了服务器@linuxfans.org，服务器当然能根据B的联系信息发到@linuxsir.org，@linuxsir.org再发到B。
这是消息由服务器转发的模式，大量的消息会使服务器不堪重负。
基本上可以看到有两种模式：服务器转发模式和点到点模式
转发模式的好处是：客户端间没有直接的连接，互相之间并不知道对方的ip，这就可以防止恶意客户端的攻击，但是服务器负担太重──无论是CPU负载还是带宽占用。
P2P模式的好处是：消息不经过服务器，在两个客户端同时在线的期间，这两个客户端间的通信不依赖于服务器，这时即时服务器异常也不会导致它们的通信中断，这样可以有一定程度上的可靠性，但是另一方面这种模式要求双方互相知道对方的IP，这样就给恶意客户端的攻击提供了机会。
所以总结起来，应该是两种模式相结合：
对于可信的通信目标，可以采用P2P模式，对于不可信任的通信目标则要通过服务器中转。
对于A和B两个客户端，它们在不同的通信阶段会有不同的身份：
比如A请求与B通信，于是A先通过服务器转发请求给B，在B接受请求前，A和B互为不可信通信目标，当B接受请求后，意味着B对A有了临时的信任，这时可以互报IP转入P2P模式，但如果双方没有成为好友，那么这种信任就是临时的，当一个客户端下线后再重新登录时如果还有进行通信则还要进行请求的过程，如果互相加为好友则意味着认同了对方的身份，使这种信任变为长期的信任，以后可以直接从服务器查询得到对方的IP（如果对方在线的话）。