From kmail-devel  Mon Jul 21 17:40:29 2003
From: Marc Mutz <mutz () kde ! org>
Date: Mon, 21 Jul 2003 17:40:29 +0000
To: kmail-devel
Subject: Re: CIA proposal (was: ClientInterface)
X-MARC-Message: https://marc.info/?l=kmail-devel&m=105886864022361
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============46676631280864367=="


--===============46676631280864367==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_OWCH/O2NtSTuA8D";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_OWCH/O2NtSTuA8D
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 21 July 2003 13:44, Andreas Gungl wrote:
> Am Montag, 21. Juli 2003 13:31 schrieb Marc Mutz:
> > CIA/4 can be extended with a DCOP broadcast call to all KMail
> > instances to close F, so that A can perform (index file) compaction
> > after all instances replied with a "folder F closed" message.
>
> How will you know all instances?

dcopserver knows them all. The client/server concept has to solve the=20
same thing, BTW.

> Sending a broadcast is okay, but=20
> collecting the responses would mean to have all instances registered
> somewhere.

dcopserver. The client/server concept has to... you know the rest ;-)

> What about the situation where a registered application dies?

dcopserver? If not, then the user gets prompted b/c of the timeout.=20
Either she will know the cause already ("of course, my korg crashed!"),=20
or can do something about it. The client/server .. you know.

> Wait for a certain amount of time?

Yes.

> How will you know, that it really died?

It doesn't respond anymore?

> E.g. a long search operation could be running.=20
<snip>

Why should that stop the process from responding? Even now, I can type=20
this email while performing a search and I think we agree that making=20
all Kmail operations non-UI-blocking is a good thing to have in itself.

You know, I can't understand why those points should be arguments=20
against CIA/4, while at the same time you propose a much more complex=20
protocol where almost every method call can timeout due to the DCOP=20
peer dying or performing an expensive, blocking task?

If these are your only concerns, then, hurray, we have a compromise=20
solution!

Marc

=2D-=20
Nie wird so viel gelogen wie vor der Wahl, w=E4hrend des Kriegs und nach
der Jagd                                          -- Otto von Bismarck

--Boundary-02=_OWCH/O2NtSTuA8D
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/HCWO3oWD+L2/6DgRAmhZAKCQypLQM1TYBAW0cqCwACPNX9CYFQCcCP4P
N+LbKZu15JQ2P88K9ZLPZ6k=
=hYGk
-----END PGP SIGNATURE-----

--Boundary-02=_OWCH/O2NtSTuA8D--


--===============46676631280864367==
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

--===============46676631280864367==--