From kmail-devel  Tue Jun 10 19:37:59 2003
From: Marc Mutz <mutz () kde ! org>
Date: Tue, 10 Jun 2003 19:37:59 +0000
To: kmail-devel
Subject: Re: [PATCH] UI abstraction proposal (partially only)=?iso-8859-1?q?
X-MARC-Message: https://marc.info/?l=kmail-devel&m=105532610929323
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============067185742413189864=="


--===============067185742413189864==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_YOj5+QFZJLbmGXY";
  charset="us-ascii"
Content-Transfer-Encoding: 7bit


--Boundary-02=_YOj5+QFZJLbmGXY
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 03 June 2003 12:53, Zack Rusin wrote:
<snip>
> Personally I
> like the way Outlook does it - meaning that the gui asks the core for
> some specific info and the core just sends the data. So for me DCOP
> communication.
<snip>

Sorry for disturbing the party, but did I miss something? Who had this=20
glorious idea to make a "KMail server"?

If it's all about the old dream of a command-line KMail, then my take on=20
this is that the non-GUI code needs to go into a separate lib and KDE=20
and ncurses frontends linking to that. IIRC, DCOP needs an X server and=20
I don't think you want that dependency for a mutt-like clone.

As to concurrency: The better way IMO would be to make KMail reasonably=20
robust against multiple instances acting on it's data (maildir should=20
make this relatively painless) instead of cranking up a proprietary=20
client/server protocol. That would automatically solve the procmail=20
problem, too. That doesn't mean to go out of one's way to make it fool=20
proof. It just needs to function well in the "keep running at work, but=20
allow access at home, too" case. If you need full concurrent access,=20
use an IMAP server.

I don't see why DCOP needs to be involved at all. There's no reason for=20
using it for UI<->code coupling. This is just a fruitless excercise in=20
distributed system programming. Just think about all the error handling=20
necessary to prevent a dcop shell command from interfering with a UI=20
session. You'll end up sanitizing every little parameter to every=20
little method call. And since you won't catch all cases anyway, you'll=20
end up with all sorts of problems and prossibly even security bugs.

I prefer in-process method invokation over distributed systems wherever=20
the latter is not strictly necessary. Don't use DCOP just because=20
you've just had a read through your new CORBA book and it sounded cool!

Please come up with a use case that requires DCOP/RPC and cannot be=20
handled with simple library use!

I mean, we use khtml and kabc as libs/parts, and not as server=20
processes, or do we?

Marc

=2D-=20
We notice things that don't work. We don't notice things that do.
We notice computers, we don't notice pennies.
We notice e-book readers, we don't notice books.
                                          -- Douglas Adams

--Boundary-02=_YOj5+QFZJLbmGXY
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA+5jOY3oWD+L2/6DgRAqj8AJ9Vf+436lLxx7S5QPiml7lI2h38KACdHSOq
aRjZo9uk4odx++DScZEeYGI=
=d431
-----END PGP SIGNATURE-----

--Boundary-02=_YOj5+QFZJLbmGXY--


--===============067185742413189864==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============067185742413189864==--