--===============1199856958==
Content-Type: multipart/signed;
  boundary="nextPart19453289.ULaoyjytSq";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart19453289.ULaoyjytSq
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 30 September 2005 01:58, Daniel Stiefelmaier wrote:

> I did not really get (relevant) results when i searched for IM proxy.

KIMProxy is a class of the KDE API (since 3.3) which allows to talk to IM=20
applications that implement the KIMIface DCOP interface.
(From memory that are Kopete, Konversation and Licq)

=46or example Konqueror (filemanager) uses this in its Copy-To extension wh=
ich=20
lists all contacts available for file transfer and initiates one on=20
activating the respective menu item.

You can explore the interface by using KDCOP or the commandline tool dcop.
#> dcop applicationId KIMIface
for a list of methods (or kde:KIMIface for its API documentation)

> And it does not fully cover my original approach.
> One goal was system independence. well, don't get me wrong, i guess i'll
> stay with KDE in the future. But i thought it would be an advancement to
> have one standardized addressbook, not for KDE only but for all who want
> to participate. Only one system had to be implemented and maintained.
> And users would not have to convert. Converting address books is a pain.
> you may lose entries and some uncommon fields (just like IM IDs)

True, but unfortunately nobody else has such a central addressbook framewor=
k=20
yet with which KDE could cooperate. All the other applications seem to=20
provide their own backends, e.g. Thunderbird has probably a backend shared =
by=20
Mozilla apps. Not sure the GNOME API provides anything like that, very like=
ly=20
they rely on Evolution.

KDE applications have an advantage here, they already share the addressbook=
=20
through the KABC framework and independent where it is located, i.e. if it =
is=20
local or on an LDAP server, etc.

> LDAP (directly) has the same drawbacks: It is not supported by all of
> the applications.

I haven't checked any of the mentioned applications which provide their own=
=20
addressbooks, but I think if an application is serious about using=20
addressess, e.g. being a full featured email application, it is very likely=
=20
it supports an LDAP backend.

However I agree that  user-local shared addressbook would be nice to have e=
ven=20
when non-KDE applications are involved, but I am quite confident that if=20
somebody creates a prototype for that, somebody else will try to create a K=
DE=20
address resource to access it.

Until then the already shared KDE addressbook is the best we have.

Cheers,
Kevin

=2D-=20
Kevin Krammer <kevin.krammer@gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtforum.org

--nextPart19453289.ULaoyjytSq
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDPQlsnKMhG6pzZJIRAq5gAJ489wEIOa68QyqFq2b2vY5pD/nlKACePljG
D35c5q0wFnHbjjPNcg+bLXQ=
=5CAl
-----END PGP SIGNATURE-----

--nextPart19453289.ULaoyjytSq--

--===============1199856958==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 =

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<

--===============1199856958==--