[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)
From:       Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-06-03 22:36:12
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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 
running at their workstation all the time (because it fetches their 
mail) and they want to be able to check their mail from a remote 
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 
switching to a large folder take some time. But most of the time is 
spent threading the message list. And this would happen in the GUI and 
not in the core. So we just have to make sure that the core is never 
blocked too long. But I don't think you can really compare a large J2EE 
project to our situation. In our situation there would at most be a 
handful of applications which try to communicate with the core. And in 
general only one of this applications (namely the GUI the user is 
currently using) would make a lot of calls to the core. All other 
applications would only make calls every once in a while. But maybe I'm 
just not imaginative enough.

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

Regards,
Ingo


[Attachment #5 (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]