KDE Jabber Library
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
> * 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
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
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.
More information about the kde-core-devel