KDE Jabber Library

Martijn Klingens klingens at kde.org
Sun Aug 4 16:42:10 BST 2002


On Sunday 04 August 2002 17:17, Neil Stevens wrote:
> KDE dictating a standard does not remove choice from anyone.  It just
> promotes consistency and interoperability within KDE.

Yes, but not outside KDE. And it does not take into account the fact that many 
people already have other IM accounts. Especially the latter is for me _the_ 
reason to object against forcing a user to use yet another IM system next to 
the ones they're already using.

For new IM users, I agree with promoting Jabber as 'the' backend. For existing 
IM users, no way.

> And actually, your Microsoft comment is not true.  At least as many people
> dislike MS for not following standards, and for subtlely changing
> standards to suit themselves, as people who dislike MS for making up their
> own stuff.

As far as I'm concerned they're free to do all of the above as long as they 
also support existing standards and don't pose their solution as the one and 
only way, and they document their own standards. That way the user can choose 
between the MS-way or the alternatives. Like using Gecko as rendering 
component in the Windows explorer instead of the MS HTML component. Just like 
KDE supports Gecko, KHTML and (in theory) others. Just like Opera for Windows 
supports MS HTML next to its own renderer.

> If you're not a proponent of a standard desktop, then how can you agree
> with KDE at all?  After all, KDE "removes choice" by...
>
> * having in cvs only one widget set

We have multiple styles, no?

> * mandating one capitalization standard

You can create your own i18n set to use another capitalization scheme

> * forcing one filesystem hierarchy

I have complained about some aspects of this before, but I'm not in a position 
to change it, and it more or less still works for me, so I'll live with it 
for now.

> * supplying only one window manager

You can select another. Just modify startkde. See the archives of kde-devel 
for more info, this was a recent thread.

> * supporting only one reusable component system

There's XParts already, and I would love to see BonoboParts too. You only need 
someone to actually write it, but the framework at least allows it.

> By supplying one and only one message and presense system in kdelibs, KDE
> merely makes sure that interoperability is guaranteed.  Users of KDE can
> still do whatever they want, and they always have been able to.  It's just
> apps *in* KDE that are expected to follow the mandates.

You only guaranee interoperability between Jabber users. In other words, a 
niche market. You exclude everyone already using other IM systems. That's not 
interoperable at all.

> What's the alternative to this?  I looked at kopete's protocols dir
> yesterday, and surprise surprise, of all the protocols supported, all but
> two weren't owned and locked into some proprietary private server - IRC
> and Jabber.  And *two* were owned by Microsoft, the company you seem to
> hate so much.  So what good is that?

Yes, two are owned by MS, and ICQ and AIM are both owned by Time Warner. 
What's the point? Each of those protocols individually has more users than 
Jabber.

I may dislike Microsoft's monopoly tactics of not disclosing specs and 
creating a vendor lock-in, I don't dislike most of their actual products that 
much. There's enough good stuff to be found there, and enough to bitch about. 
But that's the same for KDE or any other system, so that doesn't make a 
difference.

What I really dislike is lack of interoperability between different similar 
systems (desktops, operating systems, IM systems, whatever, just in general), 
and you are proposing exactly that for KDE's IM solution.

> As for Jabber vs IRC, I really doubt it'd be useful to have a personal IRC
> server for LAN communications, since Jabber does so much more.

As long as it's not a de facto standard it's nice to promote it, and use it 
when the user has it, but not to require the user to actually have it. 
Requiring a user to adopt a free IM system is an extremist approach that 
nobody but the most passionate free software zealot will appreciate.

Martijn





More information about the kde-core-devel mailing list