KDE Jabber Library

[Martijn Klingens]

On Sunday 04 August 2002 13:46, Dominique Devriese wrote:
> > 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.

It's not. If Psi is a sole transport library it would be, but then Psi as 
library is incomplete. You need a GUI to add a contact to your contact list, 
remove it, edit it and select it. You need backend code to store the contact 
in the KDE address book and fetch it again.

Either Psi doesn't do this, but that puts the burden on the application 
developer, which causes code duplication.

Alternatively Psi provides that itself, causing code and functionality 
duplication with Kopete.

Either way there is a huge amount of duplication that's bound to break one way 
or another with bugs that appear in either piece of code, but not in the 
other, or features that are available in one place but not in another. That's 
inconsistent, and inconsistency is the main thing we should watch for, 
because it's the most annoying to users, even power users and developers.

> The only arguments against the jabber lib that make sense to me
> are:

s/only/other/ ;-)

> 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.

True. Still, I think having a sound Kopete DCOP interface in kdelibs makes 
more sense than having a Jabber-specific interface.

> 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..

DCOP or another way of IPC. At least a daemon-like process (with or without 
GUI in e.g. the system tray) looks like a requirement 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.

If you're forced to use something you're not "convinced" but rather "required 
to". Whether your Jabber experience after that is good or not is another 
point, but at least the initial user experience ("Why the fsck do I have to 
create yet another IM account?") is negative.

If Kopete offers to create you a Jabber account upon first startup, but 
doesn't force it upon you and doesn't ask again on subsequent startups that 
sounds a lot less intrusive to me.

> 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...

With the proper code in Kopete that could be handled there as well. I've been 
thinking a little about that and there are a number of ways to solve it more 
generic, so it also works over other backends than Jabber. It's not quite a 
priority for me as long as the API is still under heavy development, but 
after that it would be a nice next step.

> 2 jabber is an open protocol, and the best that seems available.  It
> would make sense to me for KDE to support it.

If Kopete is part of KDE then KDE supports it through Kopete. We support HTTP 
through KIO instead of a libkhttp as well.

> > Basically, if you want code and feature duplication, go for Psi.
>
> As said, this is a bogus argument, see above.

See above why it's not :)

> 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.

As long as there are no Gnome games that support KGame's wire protocol that's 
a KDE internal thing, sure. But you're sending the invitation over IM, no? In 
my dictionary 'IM' reads as outside world. We could also skip tcp/ip and send 
out our own protocols. Sometimes it's better to stick with what's out there, 
and not just a single non-generic solution.

Martijn