--Boundary-02=_KnOi9xjZdb5Fzq6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Tuesday 17 September 2002 21:35, Zack Rusin wrote: > - we have KMime almost finished. 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. > 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=20 and I don't need to repeat them. People agreeing with me do so already=20 and prople disagreeing will do so even when they eventually see a=20 finished kmime, because it won't be fast enough for their 100'000 mail=20 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.=20 Here, I'd prefer majority decisions over single opinions. But I think=20 Aaron will find it easier to get patches in once it involves mere=20 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=20 in the Mulberry direction. A professional and RFC-compliant mail client=20 that leverages the _full_ potential of MIME. Giving the user full=20 control over the MIME tree in the composer kind of thing. That, of=20 course, will repeatedly set Aaron and myself on opposing seats, but I=20 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=20 until 3.1 is out and make those changes in HEAD. There's abolutely no=20 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. There are not so much technical issues. Personally, I'll concern myself=20 with filtering, KMime and the Config Dialog (aegypten integration) for=20 3.2 and I'm quite unbiased as to the rest of KMail as long as design=20 decisions are not made against the majority of the developers. I have=20 some ideas for new features and I have my code design principles that=20 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=20 kroupware_branch, for that matter) will _not_ end up being dumped onto=20 HEAD like AEGYPTEN_BRANCH was. One thing at a time. Regardless of how=20 difficult it is to separate the concepts. We saw what a PITA the=20 aegypten merge was. By all means, let's not repeat this episode. Marc =2D-=20 If privacy is outlawed, only outlaws will have privacy. -- Phil Zimmermann --Boundary-02=_KnOi9xjZdb5Fzq6 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9iOnJ3oWD+L2/6DgRAsyGAJ9JcpuU+ZntvVGvs8kqKZaiAetI7ACfYYre IgiUMqYNUAquQBOP/Yobh84= =fT+f -----END PGP SIGNATURE----- --Boundary-02=_KnOi9xjZdb5Fzq6-- _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail