From kde-core-devel Sat Aug 03 20:08:34 2002 From: Justin Karneges Date: Sat, 03 Aug 2002 20:08:34 +0000 To: kde-core-devel Subject: Re: KDE Jabber Library X-MARC-Message: https://marc.info/?l=kde-core-devel&m=102844622915728 I still don't appear to be subscribed to this list, so I will write to=20 everyone in one big mail.. Martijn: > If I'm not mistaken Kopete's Jabber plugin uses Psi internally This is true. It is actually not the revamped library, but rather an=20 extraction of code from the Psi client. Close enough, anyway. > Same for Kopete. Except that it is made for the sole purpose of > supporting not only Jabber, but also other protocols like AIM, > MSN, and what more, which makes it infinitely more usable for > most people I think. Except that only Jabber is actually useful in kdelibs. The rest are only= =20 useful to Kopete. There is no room for expansion with AIM, MSN, etc. Yo= u=20 aren't going to build a services platform on top of AIM, I'm sorry. Thes= e=20 other protocols simply aren't as flexible as Jabber, and that was part of= =20 their design decision. Of course, you must understand that I am a bit biased towards Jabber. Bu= t=20 really, we need to get away from these other protocols. I realize Kopete= =20 does a great service to people, by allowing them to connect to all sorts = of=20 networks and maintain communication with whomever. However, I believe co= de=20 related to these closed services should not be part of kdelibs. KDE coul= d=20 take a stance here and promote open-standards. Kopete is largely irrelevent to my discussion here. I'm not arguing agai= nst=20 its use, nor its potential inclusion into KDE 3.2. I'm talking about=20 kdelibs. > I think a 'standard IM client' instead of a 'standard Jabber client' > would be the better option. We have KIO to remain > filesystem/protocol independent, KParts to remain independent of a > given text or HTML viewer implementation. Along this line it would only > be obvious to also remain independent of a given IM backend. The problem is that if you take a Lowest-Common-Denominator approach to I= M,=20 you'll strip Jabber of everything good about it and reduce yourself to ju= st=20 chit-chat. This is fine for Kopete, but would make inclusion into kdelib= s=20 much less useful. > Well, see above. I'd love to see Jabber support in KDE. I don't want > Jabber to be the only IM protocol in KDE though. I think a role as plug= in > in Kopete is much nicer. And this is fine, Kopete will is not going away. > But moreover, read any other comments to this thread, since me being > a Kopete developer makes this message not as neutral as you probably wa= nt. Am I neutral either? Please don't hold back a reply. Tim: > Maybe I just dont know Jabber/XMPP well enough, but I never found a way > to use it as a signaling protocol for advanced media types (like the > VNC protocol used by Desktop Sharing) and negotiating out-of-band data. > Is there something like this for Jabber? Jabber is normally just client->server->client for communications, howeve= r=20 lately there has been much discussion about forming byte-streams between=20 JabberID's (either P2P, or through the server). There is a class in libp= si=20 called JidStream, which will probably be the basis for this. There are a= LOT=20 of possibilities here, from simple things like file transfer (the current= FT=20 protocol is not nearly as robust as this could make it), to the more=20 powerful, like network tunneling. Being able to link a direct connection= =20 from one Jabber ID to another Jabber ID rather than just IP address to IP= =20 address could be very interesting. See Jabber Enhancement Proposal (JEP)= 37=20 for further information. I'll take the time to note here again that you simply can't do this with = other=20 services, at least when you consider thru-server assistance. > My personal problem with Jabber as a foundation for IMP services in KDE > is that it is server-centric, AFAIK. This makes it pretty useless in > home and ad-hoc networks that don't have an internet connection. A > P2P protocol like SIMPLE can, together with a service discovery > protocol, very easily be used to find and display the presence... Personally, I consider the server-centric nature of Jabber to be a good t= hing. =20 It simplifies the clients, simplifies message routing, gives you DNS=20 authority, etc. But, you're right, your particular application may not be a good use case= for=20 Jabber. This does not mean there is no use for Jabber, nor does it mean = that=20 SIMPLE could not be included into KDE. Of course, as Neil brings up, there is the possibility of including a Jab= ber=20 server in the desktop itself. Then LISA could locate it I suppose. Neil: > Name it after Jabber or the protocol name, I say. No need to get=20 > misleadingly vague in the name. It only does Jabber, and that's a good= =20 > thing, so name it as such. The reasoning for the "Kimp" name is because of the IETF. The original R= FCs=20 for IMP were for a protocol named IMPP (instant messaging and presence=20 protocol). Since that never went anywhere, but Jabber intends to superce= de=20 it, Jabber has been renamed to XMPP (eXtensible) for all IETF discussion.= If=20 all these negotiations pan out as expected, then Jabber will be our stand= ard=20 IMP, in which case "Kimp" is not misleading. But "Jabber" works for me t= oo=20 :) -Justin