--===============90600122456622789==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_fvGG/2aot4vnQNy";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


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

On Tuesday 15 July 2003 22:02, Andreas Gungl wrote:
> I recommend to think over the targets to be worked for before any
> further technical discussion continues. Is it to have different UIs?

No. At least not in the foreseeable future. There are already very=20
capable text MUAs. IMO it doesn't make sense to even think about=20
writing a text KMail client.

> Is it to allow many other applications (perhaps still unknown today)
> to interact with KMail's core?

Definitely. The most important apps here are the KO and KAB parts in=20
Kontact. If Kontact is used as Kolab client then currently the KM part=20
has to run to allow KO and KAB to access the data which is stored on=20
the IMAP server (which is part of Kolab).

> Is it "only" a cleanup to separate core and UI code in the current
> codebase?

No. It's definitely more than a cleanup (see above).

I'd like to see the following (in decreasing priority):
a) We separate the backend in a (lightweight) library which will be used=20
by the KMail GUI and also by KO and KAB.
b) We finally make KMail work with other applications (including several=20
KMails) that access ~/Mail. So we need to add proper folder locking and=20
we need to watch the folders for changes.
c) We kpartify the Composer and the ReaderWin so that they can be used=20
inside other applications.

I don't think that a complete separation of KMail into a server daemon=20
and a client is a good idea. Some reasons:
=2D Communication via DCOP causes much overhead because every little piece=
=20
of data has to be put into a stream and has then to be read again from=20
the stream. With a) this isn't necessary.
=2D We would have to add a whole lot of error handling code for each DCOP=20
communication. Again with a) this isn't necessary.
=2D We would have to add scheduling code to the server to make it work=20
with concurrent clients. With a) and b) this isn't necessary.
=2D DCOP can only be used to exchange messages on the local machine. So if=
=20
the user wants to run multiple KMails on different machines accessing=20
the same ~/Mail directory (e. g. via NFS) the server/client separation=20
doesn't help at all. b) solves this problem.

BTW, a simple solution for the callback stuff is the usage of signals=20
and slots. I don't think it's necessary to add C-style callback=20
functions just to be able to get some error messages from the kernel on=20
the screen.

Regards,
Ingo


--Boundary-02=_fvGG/2aot4vnQNy
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/GGvfGnR+RTDgudgRAux4AKDJN2vuHR5hL+NPW9ghos6SUT0FGgCcCU91
Ll4biqB9/IJI6nzKIX/x9Ic=
=w63+
-----END PGP SIGNATURE-----

--Boundary-02=_fvGG/2aot4vnQNy--

--===============90600122456622789==
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

--===============90600122456622789==--