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

List:       kde-pim
Subject:    Re: [Kde-pim] Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI
From:       Marc Mutz <mutz () kde ! org>
Date:       2003-07-18 8:44:59
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 15 July 2003 22:02, Andreas Gungl wrote:
<snip>
> I'm just wondering why you didn't take part in the discussion of the
> UI separation issue some weeks ago. And I don't understand why you
> don't uncover your technical arguments pro and contra whatever
> solution. 
<snip>

I posted a while ago that I'm working on getting my diploma (master) 
thesis out of the door and thus have internet only sporadically (to 
keep me focused ;-).

First of all: I'd very much welcome work from anyone to refactor KMail 
to have a decent MVC-like design and I wouldn't mind adding _some_ 
_general_ (_C++_) interfaces for that. In fact, I'd probably also start 
with making an interface for the status bar service that the main 
window provides, however, it would be KMail-internal, called StatusBar 
and KMMainWindow would implement it in terms of it's KStatusBar.

So I'm mainly opposing the split of KMail into a server and a client. 
That's opening a can of worms w.r.t.:

1. Compatibility of the on-the-wire format: who here can guarantee that 
you keep the protocol stable for at least three years, which is the 
minimum update interval for companies? Think back where KMail was 
three(!) years ago. Do you want to keep interfaces that old? Now that 
KMail slowly starts to get a decent internal design again? Do you want 
to maintain the forwards- and backwards compatibility layers that are 
necessary that KMail/Home can work with a two-years-old KMail/Work? If 
not, then I'd suggest we forget this idea again. Don knows this, which 
is why he wrote:

On Friday 11 July 2003 09:22, Don Sanders wrote:
> Could you please add a note to clientIface.h stating:
> "KMailClientInterface is subject to change without notice and
> not yet part of the standard KDE API."
> This is to avoid the need to keep backwards compatibility with third
> parties, and make sure that we are free to change this API at will.
> Initially I would like to restrict the use of this interface to
> kde-pim.

But that's not going to work out since the problem is not cross-module 
compatibility, but cross-version compat (see above). The "third party" 
here is KMail 1.8!

2. Distributed systems: I don't know about you, but I find debugging 
multi-threaded and otherwise concurrent or distributed applications a 
real horror. If neither you nor a decent percentage of other KMail 
developers have any real-world experience with this, I'd suggest we 
forget this idea again.

<rant>
All this "kmail server" - sorry - nonsense is just trying to work around 
KMail's inability to have decent locking and new-mail-detection for 
~/Mail and other stuff. But instead of fixing _that_, removing business 
logic[1] from GUI classes and splitting off a libkmailcore.so that a 
KDE and a curses front-end could link against and instead of getting 
KMail's immense appetite for memory under control, the advocates of 
this proprietory IMAP replacement just try to fix the symptoms.
</rant>
What I've heard as arguments of LT2k3 pro the client-server design was 
exactly that:
  1. Multiple KMail instances'd take too much RAM.
  2. KMail wouldn't like other instances accessing it's index files.
Are there more arguments for a client-server "design" than those? Funny 
thing is that everyone (correct me if I'm wrong) that I talked to there 
about this now seems to agree that this would just be a a masturbation 
in distributed computing.

Another thing: KMail interfaces don't help KDE as a whole a lot. Small, 
task-oriented interfaces such as those that David, Danimo, et al. came 
up with for Kontact do, since they stand a chance of being implemented 
by other KDE MUAs (you know that there are two others? ;-)). If a 
method's signature contains (..,Q_UINT32 sernum,...), then it's 
completely worthless.

OTOH, linking to a kmailcore.so is cheap on the resources, forces a 
business logic/UI separation just as well (if not better) and in 
addition forces us to make KMail robust w.r.t. "external" accesses in 
~/Mail and memory usage. Furthermore, this allows programs such a KOrg 
to send emails (invitations) without a running KMail instance. KDE apps 
don't need a running instance of Konq to access http or ftp URLs, now 
do they? They don't need a running kaddressbook to access the 
addressbook, they don't need a running KOrg to parse iCal, they don't 
need a running Konq to display HTML pages. Why the heck should KMail be 
so special that all these examples don't hold for it?

Marc

[1] That's the common term for what Don calls "kernel code", something 
that is but a KMail-ism uncomprehensible to anyone but KMail 
developers.

-- 
It's good fortune for the government that the masses don't think.
                                                         -- Adolf Hitler



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

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/


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