--===============0529001630==
Content-Type: multipart/signed;
  boundary="nextPart3127639.l8qeeb80K3";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3127639.l8qeeb80K3
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 11 May 2008, Sander van Grieken wrote:

> Why should the server have control of the GUI directly (i.e. have a conce=
pt
> of a UI or Window)? IMHO a server should just send out
> signals/notifications on which the UI should act. If a 'conversation' nee=
ds
> to take place, the server could send out a signal/notification
> synchronously, which triggers the UI to perform the conversation with the
> user, and then returns a result from the conversation.

Right, this is part of the current interface. We probably could split that =
in=20
two interfaces, one for the reporting and one for getting a parent window I=
D.

> This way the server can stick to the domain model, and the UI
> implementation does not need to conform to and expose a UI interface.

The server doesn't use any UI, but resources or agents might, e.g. data typ=
e=20
specific conflict resolving.

In a traditional setup, where one application has direct control over the=20
backends it uses, it can always pass its window ID at any call which result=
s=20
in backend actions.
However, in an Akonadi setup, resources work on their own or are triggered =
by=20
the server (e.g. through cache policies).

Of course there might be better ways of solving that, we'll appreciate any=
=20
suggestions.

> It all sounds a bit like a (indirect, through dbus) circular dependency to
> me.

Hmm, I am not sure that there is any cycle. The UI part just provides a=20
service to the Akonadi setup, it doesn't need Akonadi itself.

Cheers,
Kevin

=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

--nextPart3127639.l8qeeb80K3
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

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

iD8DBQBIJvqrnKMhG6pzZJIRAibuAJ9ZXN8hNwgo9y9Y/G1b2F4YpMMElQCghPSH
dlOosJ6w0ayBMcsX3O8WFTg=
=OmhI
-----END PGP SIGNATURE-----

--nextPart3127639.l8qeeb80K3--

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

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
--===============0529001630==--