--===============74212616129638853==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_eLS3+Ggytk4dKCF";
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit


--Boundary-02=_eLS3+Ggytk4dKCF
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 03 June 2003 22:43, Andreas Gungl wrote:
> Well, I thought only about having an interface of choice when I start
> KMail - working from remote using the text UI, working locally using
> the GUI. I didn't think about many concurrent applications using the
> core simultaneously.

But that's what the people actually want. They want to keep their KMail=20
running at their workstation all the time (because it fetches their=20
mail) and they want to be able to check their mail from a remote=20
computer via a text UI KMail.


> So the conclusion out of the thread is up to now:
> - KMail should have a core which is able to manage more than one UI
> client. An UI client could be another programm like KOrganizer too.

Yes.

> - Currently we see DCOP as the way to go for the interaction between
> core and UI client.

Yes.

> - Usually, that kind of communication uses coarse grained interfaces.
> - As I understood, the core is working singular (no parallel threads
> or so). Calls will be needed to be queued somehow. (Did I get this
> right?)
>
> The requirements above make my example approach nearly obsolet.
> However, I still think, there are some more issues to be discussed.
> The architecture you prefer has some more challenges. What about
> session states (stateless, I guess), what about transactions (e.g.
> deleting 10 messages in one folder; no problem when the core is not
> working parallel), what about response times towards the UI (might be
> a problem when the core is not working parallel)?

We already have a problem with response times now. Some actions like=20
switching to a large folder take some time. But most of the time is=20
spent threading the message list. And this would happen in the GUI and=20
not in the core. So we just have to make sure that the core is never=20
blocked too long. But I don't think you can really compare a large J2EE=20
project to our situation. In our situation there would at most be a=20
handful of applications which try to communicate with the core. And in=20
general only one of this applications (namely the GUI the user is=20
currently using) would make a lot of calls to the core. All other=20
applications would only make calls every once in a while. But maybe I'm=20
just not imaginative enough.

To sum up: Currently I see a complete split of KMail core and KMail UI=20
with DCOP as glue between the two as ultimate goal.

Regards,
Ingo


--Boundary-02=_eLS3+Ggytk4dKCF
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA+3SLeGnR+RTDgudgRAsAiAKCYGno8GdT8igP931u2VCqmlIU7bQCgqM7J
mbj4KJD4x10pEFrqfiKfSuo=
=MS/6
-----END PGP SIGNATURE-----

--Boundary-02=_eLS3+Ggytk4dKCF--

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

--===============74212616129638853==--