From kmail-devel  Sat Jul 19 22:13:33 2003
From: Marc Mutz <mutz () kde ! org>
Date: Sat, 19 Jul 2003 22:13:33 +0000
To: kmail-devel
Subject: Re: [Kde-pim] Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI
X-MARC-Message: https://marc.info/?l=kmail-devel&m=105865326229876
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============89358589906113783=="


--===============89358589906113783==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_OKcG/lqx2rhZvrs";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_OKcG/lqx2rhZvrs
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 18 July 2003 23:51, Ingo Kl=F6cker wrote:
<snip>
> If Kontact is used as Kolab client then currently the KM
> part has to run to allow KO and KAB to access the data which is
> stored on the IMAP server (which is part of Kolab).
<snip>

This special example is not a valid use case for a KMail client/server=20
architecture, because there's no need to have a KMail process running=20
for this at all - be it monolithic or client/server. IMAP is very=20
capable to handle multiple connections itself. It's only that KMail is=20
currently needed for disconnected mode. I've expressed earlier that I=20
think that moving the caching necessary for disc-IMAP into the kioslave=20
or a meta-kioslave that uses the normal IMAP slave internally should be=20
possible without locking issues (think maildir for message fragments).=20
Of course, it won't be done tomorrow, but then, online IMAP can be used=20
until the slave is enhanced.

That said, if we really, really, really want a KMail server, then we=20
should port one of the more simple IMAPd's to work with KMail's index=20
files and subdirectory conventions as backend and let KMail instances=20
connect to that thing in online mode. That would be much more flexible=20
since other clients can connect, too, and it would free us from the=20
need to define a proprietary wire protocol, with all the security=20
issues involved.

And don't try to tell me that IMAP would not be suited to this task.=20
I've definitely listened too long to Martin Konold to not know that=20
IMAP is one of the most scalable, efficient and fast protocols for=20
serving out data that exist today. DCOP won't be any match.

Marc

=2D-=20
[Norton SystemWorks 2002] Wipe Info uses hexadecimal values to wipe
files. This provides more security than wiping with decimal values.
                           -- Norton SystemWorks 2002 Manual, p.160
                              (seen on Cryptogram 12/01)

--Boundary-02=_OKcG/lqx2rhZvrs
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/GcKO3oWD+L2/6DgRAqLHAJ0esBRRPjCUzJYWPmFFAizh9hTuqQCg35q0
jLRj+F2preSxYX4iTW/8Wm0=
=KQKT
-----END PGP SIGNATURE-----

--Boundary-02=_OKcG/lqx2rhZvrs--

--===============89358589906113783==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

--===============89358589906113783==--