KDE Jabber Library

[Jörg Walter]

On Sunday 04 August 2002 20:29, Zack Rusin wrote:

> Well, this question should be asked the other way around. What psi
> provides that libkopete doesn't? I just want to see a list saying
> "libkopete can't do ... and psi provides ..." or maybe a sample use
> case like 'lets say kcoolgame wants to let users chat and it needs
> to... so it can't use libkopete because...'.
> At this point psi is a pure Qt lib, whereas libkopete actually uses
> kdelibs. I'm not sure why we would put psi inside kdelibs when it
> doesn't use anything from kdelibs. Sure it might be useful but so is
> Boost and it's not a good enough reason to put it in kdelibs.

My 2 eurocents why I like to see jabber as _the_ standard IM protocol in KDE 
(including answers your questions - warning, this is detailed, thus a long 
reading):

1) some high-level feature-comparison: Jabber is an open standard, jabber is 
decentralized (run your own server, choose among many free public servers, 
...), Jabber interfaces to other messaging systems (aol, icq, msn, yahoo, 
email, irc, ...), but on the server side (not much of a difference, but ... - 
more details below)

2) about the protocol itself (this passage may apply to SIMPLE as well, only 
heard of it today, don't know it): Want to send a game invitation? With 
jabber, you invent your own message format if there doesn't exist anything 
suitable and just send it - no one will go and misinterpret it as a text 
message. Ever seen Coccinella? http://hem.fyristorg.com/matben/ - cool 
whiteboard app (cross-platform due to Tcl/Tk) which works over jabber. Want 
to have your regular jabber client running at the same time? just do so, they 
are independently addressable - and we didn't use any OS/Desktop support to 
share connections or anything.. oops, did we send a whiteboard to someone not 
using coccinella? no problem, he won't be flooded with undecipherable 
rubbish, since the (every!) Jabber client can tell this is not a text 
message. These are two examples of how the protocol itself is built for 
interoperability, regardless of OS, Desktop, Programming language, ...
Want a game with invitation and chat? No problem there, the game can connect 
as yet another presence, plain chat goes straight to the game, no need to 
filter and dispatch anything. So do the game's custom control messages.
With other IMSs, you would have to encapsulate data in chat messages, hope 
that the other side can either interpret these messages or won't choke on 
them, need to figure out which message is destined for which program, ...

3) interoperability with other IM systems: It has had it's weaknesses, but 
nowadays the software is stable, and other IM systems don't block anyone any 
longer - they seem to have recognized that it is good if others use them. As 
for the ease of setting this up, it can be improved, but that's a client 
software issue. The advantage of having the server manage the multi-protocol 
layer is that you will have your setup always and everywhere. No KDE at work? 
Or at school? Or while visiting your grandparents? With jabber you still get 
all your 'foreign' connections regardless of which jabber client you use. 
Again, this is interoperability at work.

4) Managing contacts: Jabber uses a server side contact list, so you don't 
need to interface anything on the OS. Actually, libpsi might even provide a 
backend for the KDE address book so it is stored on the jabber server (not 
sure how fesible this is, but from my knowledge it should be doable with not 
too much effort). Get a public jabber account and go, no need to setup an 
LDAP server. (Is LDAP supported?)

5) Plain old IM: you got me there, for this an app like Kopete might be more 
suitable due to easier setup (no need to create a Jabber account). But IMHO 
this is not the goal of libpsi (or rather, the propsed libim...). All the 
non-chat elements are what makes jabber much more suitable.

6) Setup complexity: it is a small price to have one jabber account created. 
This is painless and fast (choose from a list of public servers, enter 
username, password and done, total 20 seconds), it is neccessary only once 
ever for a user, it doesn't conflict with your other IM accounts, it doesn't 
entitle you to receive yet another bunch of spam via IM, client banners or 
mail, and is as anonymously as you like. Now compare that to <insert your 
favourite online game here>, where you register once for each product and on 
each computer, get tons of spam, can't trust them buggers about what they do 
with your data, ... - IMHO a small price to pay. For the kdegames case, 
someone could even provide a public kgame-only jabber server with 
auto-registration, so the registering step could be handled transparently. 
This would also eliminate the problem that you might want to play with one 
MSN and one ICQ user, having those accounts you can see them, but they can't 
see each other. Enforcing Jabber eliminates that.

Summary: if people just want to send some messages to other users, let them do 
so whatever way they want, be it kopete, psi, kit, ...
But in the very moment we want to use the possibilities of this technology, a 
cross-protocol solution based on protocols like ICQ or MSN is a bad choice 
and will yield trouble, since it was not designed for what we want to do. And 
setting up an account is not the pain some people suggested.
OTOH, if this SIMPLE protocol is what it sounds to be, then it may make sense 
to support that one some day, since it sounds as if jabber and SIMPLE share a 
lot of functionality. But a good quality jabber lib is here today, 
well-tested, stable, while I think there is nothing for SIMPLE. And from the 
resons pointed out above, any other protocol is not really suitable for usage 
besides simple chatting.
(and libpsi will use KDE soon, I am sure, otherwise what point would be 
putting it in kdenonbeta)
One thing though, I think libpsi (even when renamed to a generic name) should 
go into kdenetwork for the time being, since I believe no one can predict the 
requirements for an abstract IM API, using IM for things other than plain 
chatting is too new. When common requirements crystallize, maybe someone did 
a SIMPLE lib, and then an abstract API can be created for kdelibs. Just give 
it time to develop.

CU
	Jörg