[Kde-pim] Intra-module dependencies in kdepim
Volker Krause
vkrause at kde.org
Mon Oct 5 15:51:57 BST 2009
Hi,
as you probably know, there have been various problems with the dependencies
inside the kdepim module since the runtime/apps split of the release
tarballs. With moving the most used stuff out of akonadi_next into kdepimlibs
the most pressing issues have been resolved recently, but there is still more
to do. Since I have to introduce some more dependencies I though it might
make sense to clean some of this up before ;-)
akonadi_next: A development playground for new components for libakonadi, some
if which is already used by applications before it is API-stable. The number
of actually used stuff is reduced to zero again I think, so no immediate
problem, but this will likely change again in the future.
Possible solutions: experimental library as part of kdepimlibs like it has
been done for KNotificationItem or copies in every module that uses it. Since
we only have four at most (apps, runtime, extragrear, playground), temporary
copies and more aggressively pushing to kdepimlibs seem the least ugly
solution to me.
libkdepim: A total nightmare as nearly everything uses it. Fortunately most
classes in there are independent from each other though. I propose we try to
eliminate that one step by step:
- move stuff that is only used in one place to that application, the KScoring*
stuff for example is only used by KNode and there is next to no chance that
KMail will ever use it in the future.
- do not allow to put new stuff in there
- push stuff used in multiple places into kde[pim]libs, the date/time edit
widgets to kdelibs for example, or the uistatesaver
- let's see what still remains after that ;-)
The goal would be to have less and less components depending on libkdepim
which gives us more freedom when moving stuff around and avoids the libkdepim
copy in the runtime tarball.
akonadiconsole: ended up in runtime, due to the dependency mess. Should IMHO
be moved back to apps. The only blocker currently is akoandi/kcal AFAICS.
That seems to contain mainly obsolete models (not using ETM yet), so we could
just move that into akonadiconsole for now, which avoids that they get used
anywhere else.
examples: there are a bunch of examples in akonadi/clients, more are part of
the upcoming merges from the akonadi-ports branch. They should be independent
of internal/non-installed libs and eventually moved to the kde-wide example
module IMHO. Even if that will not be created (I haven't seen the result of
that discussion yet), our examples should probably not be in the runtime
module, kdepim/examples maybe? or somewhere in playground/pim?
Now on to the new stuff: I'm about to merge the current state of
libmessageviewer from the akonadi-ports branch. That's the Akonadi/KMime port
of the message viewer of KMail, extracted and made a stand-alone library
(depending, among other things, on libkdepim, libkleo and libkgpg, ie. three
libs in kdepim/apps, not movable to kdepimlibs currently). Besides KMail (and
hopefully KNode) this will also be used by the Nepomuk email feeder agent, to
do message decryption. With the feeder agent currently in kdepim/runtime, you
can see what made me think about the dependency mess in the first place ;-)
Despite obviously belonging into kdepim/runtime the only possible solution I
can see currently is to move the feeder agent to kdepim/apps. It shares a
small amount of code with the agents for contacts and calendar, this would
need to be copied for now. Some of this is at least supposed to end up in
libraries eventually.
To at some point move it back to runtime we would need to get rid of its
libkdepim dependency, get rid of the deprecated libkpgp and make libkleo and
libmessageviewer API-stable and move them to kdepimlibs, so this is only a
very long term option.
What do you think?
regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091005/4f320255/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list