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

List:       kmail-devel
Subject:    Re: Last attempt at reconciliation
From:       Marc Mutz <mutz () kde ! org>
Date:       2002-09-18 20:59:19
[Download RAW message or body]

On Tuesday 17 September 2002 21:35, Zack Rusin wrote:
<snip>
> - we have KMime almost finished.
<snip>

That's stretching it a bit...

> Comments?

My position on this is clear - obviously.

> - we have two approaches to integrate KMail with kdepim packages.
> kgroupware has one and make_it_cool has one.
<snip>
> to go. Comments?

We have only one approach that we agree on - the Kaplan one.

> - now people have problems with changes in make_it_cool. I want to
> know exactly what changes from make_it_cool bother you so much, so in
> no particular order:
> o my folder rework, asynchronous access to all folders, common
> interface, all folder use kmfolderjob, no distinction between local
> and imap folders. Problems? What? Why?

None conceptionally. Have no time to look at the details currently.

> o Don's KMail as KPart, KMMainReadWin addition and zero-copy parsing
> with mimelib - I already talked about the first, Don cleaned up the
> second and fixed things which seemed to bother some people when it
> was in HEAD, has anyone better approaches to the third? I remember
> that one being a major problem, so let's come up with solution we all
> can be happy with.

Well, I'll be quiet on the last one. I produces all the arguments I have 
and I don't need to repeat them. People agreeing with me do so already 
and prople disagreeing will do so even when they eventually see a 
finished kmime, because it won't be fast enough for their 100'000 mail 
folders. But I prefer maintainability and RFC-correctness over speed.

> o Aaron's work on GUI - IMHO Aaron is by far the biggest usability
> expert among us, I trust all his judgments. Did anyone have a problem
> with him having a free hand in making needed GUI changes?

In the branch? No. In HEAD, that would be something else, obviously. 
Here, I'd prefer majority decisions over single opinions. But I think 
Aaron will find it easier to get patches in once it involves mere 
porting from one branch to the other.

A problem that I see coming up in this area is that I'd like KMail to go 
in the Mulberry direction. A professional and RFC-compliant mail client 
that leverages the _full_ potential of MIME. Giving the user full 
control over the MIME tree in the composer kind of thing. That, of 
course, will repeatedly set Aaron and myself on opposing seats, but I 
hope to solve such problems in discussion.

> o Daniel wants to refactor a lot of stuff - getting rid of the KM
> prefix, putting classes in the KMail namespace and putting files into
> a more approachable dir structure. Any problems with that?

Yes! That's something that can make porting a horror. Let's delay that 
until 3.1 is out and make those changes in HEAD. There's abolutely no 
need to rush this other than making porting more difficult.

> Please, remember to concentrate on the mail client, not self-pride,
> while commenting. For god sake, let's finally agree on something and
> resolve all issues people might have.
<snip>

There are not so much technical issues. Personally, I'll concern myself 
with filtering, KMime and the Config Dialog (aegypten integration) for 
3.2 and I'm quite unbiased as to the rest of KMail as long as design 
decisions are not made against the majority of the developers. I have 
some ideas for new features and I have my code design principles that 
I'll try to defend, but other than that, I see no problems.

That is, as long as it's understood by all that make_it_cool (or 
kroupware_branch, for that matter) will _not_ end up being dumped onto 
HEAD like AEGYPTEN_BRANCH was. One thing at a time. Regardless of how 
difficult it is to separate the concepts. We saw what a PITA the 
aegypten merge was. By all means, let's not repeat this episode.

Marc

-- 
If privacy is outlawed, only outlaws will have privacy.
                                                    -- Phil Zimmermann

[Attachment #3 (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]