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

List:       kmail-devel
Subject:    Re: [Kde-pim] Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI
From:       Andreas Gungl <a.gungl () gmx ! de>
Date:       2003-07-19 22:28:20
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

first of all, I'm replying to Ingo's message because I think, his and 
Carsten's response were the most constructive comments on my question for 
the targets of the KMail development in the next time.

All others tend to get religious, and this is what I would like to avoid. As 
an answer to some lines in Marc's message, yes I do have experience with 
multi-tier applications. And this is why I don't mind to fight for the 
"hey, we do it by DCOP" solution. I do see the problems with multiple 
processes. I'll explain my intentions later.

What I would like to see in KMail 1.6 is:
- - improved IMAP
- - stable, full Kolab support
- - improvements in usage / look and feel

These are things I expect as an user. As a developer I would like to see 
improvements in the application architecture, and one of these is the UI 
separation or better (more common) the MVC pattern.
If KMail could handle locks in a save way too, I would appreciate it. There 
are opposite opinions about it. Would be good if someone could work on it 
(and finally find a way) - but it doesn't help to have good ideas only and 
lack the time to realize them. Perhaps it's unfair to mention KMime here. I 
didn't follow the code or commits, but what I know only from reading the 
mailing list, this thing is still far away from being complete. If I'm 
wrong, then I do apologize.
Making the ReaderWindow and Composer KParts sounds well too. But I think, 
here the work would be easier when we have sorted UI relevant code and core 
code (business logic, kernel or whatever you may want to call it).

As I have thought a lot about the separation and as I've dealt with DCOP, I 
want to make a suggestion from which I do hope that it's a good chance to 
reach a consensus.
We should start without DCOP but use the current C++ and (where usefull) 
Signal/Slot mechanisms. This is to
- - avoid a lot of work writing the DCOP related code for streaming the data 
and handling errors in the DCOP layer
- - simplify debugging in this early stage of the separation process
- - avoid unnecessary risk in the 3.2 release in which the separation will 
certainly not be finished.

Even without DCOP we'll have to decide a lot of details. Let's say you have 
the following (pseudo) code somewhere in the core:
deep_in_core_function()
{
  do(something);
  miss_some_data;
  okay = open_password_dialog(i18n("user information"));
  if (okay) {
    do_my_work();
    Messagebox("i18n("everything okay"));
  }
  else
    finish();
}
IMO the function has to be rewritten to have return codes (others may prefer 
exceptions) to signal that an user interaction is needed outside the kernel 
code. So the function should not return "true" or "false" but "done", 
"failed", "password_needed_retry_possible". Second, it's not a good style 
to keep UI relevant information like the text for the messagebox in the 
core. It was easy to program it this way in the beginning, but if you want 
a consequent separation, then the text belongs in the UI code.

Doing this little bit of refactoring will be a lot of work even without 
DCOP. You should also keep in mind, that a good separation simplifies the 
introduction of DCOP when we find out that it's really needed. It could be 
done in a very short time then. And it could be done at any time.

But currently it would make sense to concentrate on code like the pseudo 
code above. Resolving some of such code for 3.2 is a realistic goal and 
might help to clean up the application and to prepare the way for further 
changes or enhancements. OTOH this way allow us to go with little steps. 
It's not something which is done better in one step like a 
"KPartification". And these little steps are why I would like to work on 
it. I cannot guarantee to have time to make big changes in one rush as 
sometimes needed for the Kolab related work. But I can do one small 
improvement after another.

I hope, that you can accept this suggestion. In this case I would try to 
provide another patch. Otherwise I'll wait for a decision in NH.

Andreas

On Friday 18 July 2003 23:51, Ingo Klöcker wrote:
> On Tuesday 15 July 2003 22:02, Andreas Gungl wrote:
> > I recommend to think over the targets to be worked for before any
> > further technical discussion continues. Is it to have different UIs?
>
> No. At least not in the foreseeable future. There are already very
> capable text MUAs. IMO it doesn't make sense to even think about
> writing a text KMail client.
>
> > Is it to allow many other applications (perhaps still unknown today)
> > to interact with KMail's core?
>
> Definitely. The most important apps here are the KO and KAB parts in
> Kontact. If Kontact is used as Kolab client then currently the KM part
> has to run to allow KO and KAB to access the data which is stored on
> the IMAP server (which is part of Kolab).
>
> > Is it "only" a cleanup to separate core and UI code in the current
> > codebase?
>
> No. It's definitely more than a cleanup (see above).
>
> I'd like to see the following (in decreasing priority):
> a) We separate the backend in a (lightweight) library which will be used
> by the KMail GUI and also by KO and KAB.
> b) We finally make KMail work with other applications (including several
> KMails) that access ~/Mail. So we need to add proper folder locking and
> we need to watch the folders for changes.
> c) We kpartify the Composer and the ReaderWin so that they can be used
> inside other applications.
>
> I don't think that a complete separation of KMail into a server daemon
> and a client is a good idea. Some reasons:
> - Communication via DCOP causes much overhead because every little piece
> of data has to be put into a stream and has then to be read again from
> the stream. With a) this isn't necessary.
> - We would have to add a whole lot of error handling code for each DCOP
> communication. Again with a) this isn't necessary.
> - We would have to add scheduling code to the server to make it work
> with concurrent clients. With a) and b) this isn't necessary.
> - DCOP can only be used to exchange messages on the local machine. So if
> the user wants to run multiple KMails on different machines accessing
> the same ~/Mail directory (e. g. via NFS) the server/client separation
> doesn't help at all. b) solves this problem.
>
> BTW, a simple solution for the callback stuff is the usage of signals
> and slots. I don't think it's necessary to add C-style callback
> functions just to be able to get some error messages from the kernel on
> the screen.
>
> Regards,
> Ingo

- -- 
    ~
  ' v '
 //   \\
/(     )\  Powered by Penguin.
  ^ ' ^

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/GcYMVhjiFd4beU8RAr/yAJsGN2i7Tib93iSfE2DReNUmE8bdNACgnslz
K990QlYSKddyx/4edcJa0eo=
=fqyr
-----END 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]