trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: September 2016

Re: [trinity-devel] Some toughts about knotes

From: Luke Kenneth Casson Leighton <lkcl@...>
Date: Sun, 18 Sep 2016 10:10:29 +0100
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Sun, Sep 11, 2016 at 10:16 PM, deloptes <deloptes@...> wrote:
>
> Hi,
> I would like to have your opinion on knotes. Perhaps someone of you has
> background knowledge why some decisions were taken (or not).
>
> While reviewing the syncevolution backend (I will upload it to syncevolution
> sometime soon), I started digging deeper into knotes.
>
> I first opened
> https://bugs.trinitydesktop.org/show_bug.cgi?id=2688
>
> for the libkcal, and then noticed that knotes uses libkcal Journal
> (internally), while externally a knotes interface is exposed.
>
> The question is (I did not look too deep) if there is a way to skip the dcop
> interface and access the libkcal functions directly.

 please do NOT bypass the dcop interface, it is a critical part of KDE
(now TDE).

 what happens if someone writes a replacement knotes back-end and
wants to test it seamlessly?

 what happens if someone writes a networked variant of DCOP (which
i've planned to do for a long long time) that allows remote
authenticated "Notes" management?

 if you *bypass* DCOP and use libkal directly, you've just TOTALLY
defeated what makes KDE (now TDE) so powerful and flexible.

 please DO NOT design applications that bypass DCOP.  if you have to
extend libkcal, extend libkcal and then extend the corresponding DCOP
interface as well, but DO NOT bypass DCOP.

 you will be violating one of the fundamental design principles of the
entire project by doing so.

 i trust that that is clear.

 l.