KDE Jabber Library
klingens at kde.org
Sat Aug 3 10:20:23 BST 2002
(Note: for hopefully obvious reasons this mail is quite biased, so I hope
other, more neutral people can pick up this thread as well. I won't comment
to this thread anymore than just this mail, except to answer any technical or
questions because I feel my personal opinion is too biased to count here.)
On Friday 02 August 2002 00:50, Justin Karneges wrote:
> I am the author of Psi, a Qt-based Jabber client. See http://psi.sf.net/
> for details. Recently, I have been working on a Jabber client library
> based on the Psi backend. The library is accessible in KDE CVS, under
And to make the issue worse for both of us, I'm one of the Kopee developers,
and Kopete is a KDE-based multi-protocol instant messaging client which also
supports Jabber. It's in kdenonbeta/kopete.
> It is not finished yet, but I am already quite proud of it. The Psi Jabber
> backend has undergone 3 revisions since it began over a year ago, this last
> one mainly a move to a library. It is completely based on Qt, and makes
> use of signals/slots, QObject, full unicode, etc.
If I'm not mistaken Kopete's Jabber plugin uses Psi internally
> My proposal is to rename the library to "kimp" (to stand for KDE Instant
> Messaging and Presence) and for it to be included and developed within
> kdelibs. As a member of the Jabber Software Foundation (or JSF, see
> http://www.jabber.org/), I am involved very much with the Jabber
> development process and advocacy. Many of us have wanted to
> "Jabber-enable" a desktop environment, and I think KDE would be a great
> place to begin.
And I was going to propose libkopete very soon. Either for KDE 3.2 or 3.3,
depending on how soon we can get libkopete safe for BC issues. Conflict? :)
Currently we're working on the way Kopete handles the contact list, so it can
use the KDE address book instead of its own internal list soon. Many other
issues are already unified between the plugins, other issues still remaining.
I think the most realistic roadmap for Kopete is to put it into kdenetwork for
3.2 as standalone app, because by then the user side of things will be mature
enough, and to move libkopete to kdelibs for 3.3 when it is sorted out as
well. That's only guessing though and of course seriously depends on the
amount of work we can get done for each release.
> There is a lot of potential here. By putting kimp in kdelibs:
> - Any KDE application could utilize Jabber easily. Not only for just
> chit-chat, but also for ease of detecting presence and sending data between
> users / desktops.
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.
> - It could be used as a foundation for an IM services platform (a la
> WindowsXP and MSN). KDE could keep track of your Jabber connections, have
> a wallet, etc.
> - I'd like to see jabber:// URIs, and the notion of a standard Jabber
> client (just like standard web and mail clients). There is already a
> proposed URI spec at jabber.org, but no environment has yet to use it.
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.
> Of course, kimp would only supply a Jabber library, analogous to an http
> library. Much of this stuff above could/would actually be implemented as
> further libraries and expansion. I just wanted to point out the
Along that line the presence of Psi in Kopete is only logical, since kio_http
is also inside KIO's framework :)
> By making Jabber so easily accessible from KDE, I think we'd see a lot more
> buzz and developer interest in both KDE and Jabber. What do you think?
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
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.
More information about the kde-core-devel