[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE Jabber Library
From:       Klas Kalass <klas.kalass () gmx ! de>
Date:       2002-08-03 12:55:47
[Download RAW message or body]

Justin,

after reading both your emails I think Martijn has very good points. What is 
the advantage of having a pure Jabber library? Is there any reason why all 
your ideas could not be done with kopete? 
If you work in the kopete team, wouldn't it still be possible to include all 
the fancy stuff only Jabber supports?

And what do people think about some kind of slight preference for Jabber: When 
someone starts kopete for the first time he could have the Jabber plugin 
enabled by default and the Options: 
- Create new Jabber Account
- Use Existing Jabber Account
- 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 
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 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
> > 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 long 
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 Jabber
> 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

[prev in list] [next in list] [prev in thread] [next in thread]