KDE Jabber Library
justin-qt at affinix.com
Sat Aug 3 21:08:34 BST 2002
I still don't appear to be subscribed to this list, so I will write to
everyone in one big mail..
> 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
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
useful to Kopete. There is no room for expansion with AIM, MSN, etc. You
aren't going to build a services platform on top of AIM, I'm sorry. These
other protocols simply aren't as flexible as Jabber, and that was part of
their design decision.
Of course, you must understand that I am a bit biased towards Jabber. But
really, we need to get away from these other protocols. I realize Kopete
does a great service to people, by allowing them to connect to all sorts of
networks and maintain communication with whomever. However, I believe code
related to these closed services should not be part of kdelibs. KDE could
take a stance here and promote open-standards.
Kopete is largely irrelevent to my discussion here. I'm not arguing against
its use, nor its potential inclusion into KDE 3.2. I'm talking about
> 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 IM,
you'll strip Jabber of everything good about it and reduce yourself to just
chit-chat. This is fine for Kopete, but would make inclusion into kdelibs
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 plugin
> 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 want.
Am I neutral either? Please don't hold back a reply.
> 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, however
lately there has been much discussion about forming byte-streams between
JabberID's (either P2P, or through the server). There is a class in libpsi
called JidStream, which will probably be the basis for this. There are a LOT
of possibilities here, from simple things like file transfer (the current FT
protocol is not nearly as robust as this could make it), to the more
powerful, like network tunneling. Being able to link a direct connection
from one Jabber ID to another Jabber ID rather than just IP address to IP
address could be very interesting. See Jabber Enhancement Proposal (JEP) 37
for further information.
I'll take the time to note here again that you simply can't do this with other
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 thing.
It simplifies the clients, simplifies message routing, gives you DNS
But, you're right, your particular application may not be a good use case for
Jabber. This does not mean there is no use for Jabber, nor does it mean that
SIMPLE could not be included into KDE.
Of course, as Neil brings up, there is the possibility of including a Jabber
server in the desktop itself. Then LISA could locate it I suppose.
> Name it after Jabber or the protocol name, I say. No need to get
> misleadingly vague in the name. It only does Jabber, and that's a good
> thing, so name it as such.
The reasoning for the "Kimp" name is because of the IETF. The original RFCs
for IMP were for a protocol named IMPP (instant messaging and presence
protocol). Since that never went anywhere, but Jabber intends to supercede
it, Jabber has been renamed to XMPP (eXtensible) for all IETF discussion. If
all these negotiations pan out as expected, then Jabber will be our standard
IMP, in which case "Kimp" is not misleading. But "Jabber" works for me too
More information about the kde-core-devel