KDE Jabber Library

[Justin Karneges]

I still don't appear to be subscribed to this list, so I will write to 
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 
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 
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 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.

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, 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 
authority, etc.

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.

Neil:

> 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 
:)

-Justin