KDE Jabber Library
trouble at garni.ch
Mon Aug 5 16:41:22 BST 2002
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
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.
More information about the kde-core-devel