[Kroupware] DCOP/Kaplan vs. embedding KOrganizer: Pros and Cons

[Marc Mutz]

--Boundary-02=_Uf3k9dAEB2e0C1D
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

Hi!

I was asked to present a little technical arguments summary of the UI=20
issue that we have come across.

There are two proposed ways to handle UI integration between Korganizer=20
and KMail: The GUI shell approach (keywords: Kaplan, KParts, DCOP) and=20
the embed-KO-in-KM approach (keywords: KParts, signal/slots).

The "community" favours the Kaplan appraoch. Here are their arguments:
=2D the individual apps can run equally well inside Kaplan or as separate
  apps - the user gets to choose
=2D DCOP hides the difference between in-process and out-of-process part
  communication
=2D DCOP is fast for in-process communication
=2D The framework exists already, saving development time
  o Kaplan is in HEAD
  o KO is a KPart in HEAD already
  o KM is a KPart in make_it_cool; it should not be too difficult to=20
    port only the KMail->KPart change over to kroupware_branch.
=2D And a less technical, but nonetheless important argument: It's what=20
  the developers of KO and KM agree should go into 3.2, so merging would=20
  be easier later.

The "kroupware people" favour the embed-KO-in-KM approach. Here are=20
their arguments:
=2D Don't sacrifice stability by using make_it_cool stuff.
=2D Most work is already done. Choosing another direction isn't possible
  within the tight schedule.
=2D Without a GUI shell, the security implications are more "overseeable"=20
  (?uebersichtlicher?)

Judging from the past discussions, it seems the merging issue was=20
underrated up to now. I rather the merge will be major part of the=20
project, so keeping it in mind when discussing things is important IMO.

Thanks for reading,
Marc

=2D-=20
They [RIAA,MPAA] are trying to invent a new crime:
interference with a business model.
                           --Bruce Schneier, Crypto-Gram 08/2002

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

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

iD8DBQA9k3fU3oWD+L2/6DgRAixQAKClqUoVE3fZSlc0A9TQV5h5yOzYnQCggBQ2
ej8H0ASZgFZybBBU0CMxdh0=
=udAh
-----END PGP SIGNATURE-----

--Boundary-02=_Uf3k9dAEB2e0C1D--