From kde-core-devel Sat Aug 03 12:55:47 2002 From: Klas Kalass Date: Sat, 03 Aug 2002 12:55:47 +0000 To: kde-core-devel Subject: Re: KDE Jabber Library X-MARC-Message: https://marc.info/?l=kde-core-devel&m=102837943114409 Justin, after reading both your emails I think Martijn has very good points. What i= s=20 the advantage of having a pure Jabber library? Is there any reason why all= =20 your ideas could not be done with kopete?=20 If you work in the kopete team, wouldn't it still be possible to include al= l=20 the fancy stuff only Jabber supports? And what do people think about some kind of slight preference for Jabber: W= hen=20 someone starts kopete for the first time he could have the Jabber plugin=20 enabled by default and the Options:=20 =2D Create new Jabber Account =2D Use Existing Jabber Account =2D Use Other IM Protocol could be shown first in a setup wizard. That way it is suggested to someone not knowing about all those different=20 protocols to use Jabber but still the other protocols are easily available. Am Samstag, 3. August 2002 11:20 schrieb Martijn Klingens: > (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 comme= nt > 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.ne= t/ > > 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 > > kdenonbeta/psi/libpsi/ > > 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 IMHO Kimp sounds too much like Gimp. I think there even was some efforts lo= ng=20 ago to make a program called kimp that was supposed to be Gimp/KDE. > > 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 > > possibilities. > > 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 Jabb= er > to be the only IM protocol in KDE though. I think a role as plugin in > Kopete is much nicer. > > 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. > > Martijn Regards, Klas