KDE Jabber Library

[Dominique Devriese]

Martijn Klingens <klingens at kde.org> writes:

> On Sunday 04 August 2002 12:47, Dominique Devriese wrote:
> > I think Martijn ( or me ;) didn't quite understand what the discussion
> > is about...  As I see it, it is about having a way for e.g. a kgame to
> > send an invitation to someone else.  In this example, there is no need
> > to worry about interoperability with other desktops, since requiring
> > the use of a certain kgame already excludes all those people.
> 
> And use two different IM backends, duplicating code, spreading out 
> functionality and what more???

This is a bogus argument, there's no reason for Kopete's jabber plugin
to not use the jabber lib if it would become available.

The only arguments against the jabber lib that make sense to me
are: 
1 not appropriate in kdelibs: kdelibs is already huge.  Adding another
lib won't really help that.  This could be solved with the interfaces
thing that was suggested some time ago too for a terminal emulation
thing.
2 It would require different connections to be made to the server
every time a program wants to send a message.  Although jabber servers
can handle this very well, it does seem somewhat bad.  You are imho
right that a DCOP thing would be better here..
3 Like you also said: necessity for a new IM account.  On the one
hand, this seems like a good thing to me, cause it could convince
people to try out jabber, but on the other hand, some people might be
bothered by this.

Benefits are:
1 jabber supports a user connecting multiple times, so a kgame
invitation could be sent so that it doesn't go to Kopete, but to the
kgame program in question...  The presences allow you to check if the
other user's kgame program is running before trying to send a message,
and send it via Kopete if that is not the case...
2 jabber is an open protocol, and the best that seems available.  It
would make sense to me for KDE to support it.

> Basically, if you want code and feature duplication, go for Psi.

As said, this is a bogus argument, see above.

> If you want to keep it in one generic KDE-wide IM solution that's
> backend independent, go 
> for Kopete. The word "generic" alone doesn't make the choice hard
> for me,  
> since that's what KDE's framework is all about, generic components
> and interfaces.

KDE's genericness is indeed its biggest advantage, but you should see
that it is only appropriate when communicating with the outside
world.  HTTP, FTP... protocols (KIOSlaves), and HTML, PDF, PS... file 
formats (KParts) are standards that are independent of KDE, and that a
Desktop Environment should support.  However, there's no need for a DE
to be generic in its internals too.  E.g. there is only one Config
file format ( a XML backend was not included a while ago, iirc ), one
.desktop file format etc.  IMHO, the same applies to KGame
invitations, which are internal to KDE.

cheers
domi

PS: this is just my view on things, i don't really incline to any of
the two solutions, i just try to see the benefits of both.

-- 
TEACHER IS NOT A LEPER
TEACHER IS NOT A LEPER
TEACHER IS NOT A LEPER
TEACHER IS NOT A LEPER

	Bart Simpson on chalkboard in episode 9F08