Page MenuHomekolab.org

Figure out minimal dependency tree of libkolab
Closed, ResolvedPublic2 Story Points

Description

Preferably including why we depend on it.

Details

Ticket Type
Task

Event Timeline

mollekopf updated the task description. (Show Details)
mollekopf raised the priority of this task from to High.
mollekopf claimed this task.
mollekopf changed Ticket Type from Task to Task.
mollekopf added subscribers: vanmeeuwen, mollekopf, meier.
mollekopf edited a custom field.Apr 27 2015, 11:07 AM
vanmeeuwen lowered the priority of this task from High to 60.Apr 28 2015, 11:43 AM

Everything's medium until product owners say different.

Summary

The following usecases are currently covered by libkolab:

  • Interpretation and expansion of recurrences
  • Detection of conflicts in event-sets
  • Retrieval of current system-time
  • Attendee/Delegation-helpers for events
  • iTip/iMip reading/writing
  • iCalendar reading/writing
  • Conversion between kolab and KDE Containers
  • Generating/aggregating and serializing freebusy
  • Definitions such as types, used in the kolab MIME-message format and IMAP annotations.
  • Reading/writing of kolab objects to/from V3 MIME-messages
  • Reading/writing of kolab objects to/from V3 XML
  • Reading/writing of kolab objects to/from V2 MIME-messages
  • Reading/writing of kolab objects to/from V2 XML

Dependency tree

The following direct dependencies are deemed necessary for the functionality implemented:

  • KCalendarCore
  • KMIME
  • KContacts

We additionally depend on a single class in KCalendarUtils that we should be able to get rid of.
Further dependencies are currently pulled in by the interface for the kolab-resource.
Once we get rid of that we'll be in a much better situation.

Additional necessary indirect dependencies from frameworks are:

  • ECM (CMake scripts required by the buildsystem)
  • KI18n (possible to strip if we make translation function noops)
  • KDELibs4Support (only until all frameworks are properly ported)
  • KCodecs

Maintaining Qt4 compatibility

To keep Qt4 compatibility we would have to maintain separate codepaths for all places where interfaces changed between Qt4 and Qt5 as well as libcalendaring and frameworks.
This is in particular:

  • Timezone support
  • KABC -> KContacts
  • Various include changes

While this comes at extra effort it seems feasible using a limited set of proxy functions and #ifdefs.

Proposed plan of action

  • To reduce coupling, KDE containers should no longer be used in any interfaces (with the exception of the conversion to/from KDE containers).

This makes the interface robust against potential changes in the KDE containers, and allows to exchange implementations under the hood as required.

  • Because both the Kolab Resource and libkolab internally require a conversion to/from KDE containers, we continue to provide such facility.

This facility could be dropped from public API as if the kolab resource in akonadi-next no longer requires that translation.

  • The next version of libkolab will depend on the frameworks described and Qt5.
  • Qt4 + libcalendaring compatibilty can be restored for all parts that are required on the server in a second stage.
  • Figure out a way to get rid of KCalendarUtilities, or restructure to avoid the currently overly-large dependency tree.
  • Enhance timezone support in KDELibs4Support to get KCalendarCore to work again.
  • Port all frameworks away from KDELibs4Support.
  • Profit!
mollekopf moved this task from Review to Done on the Sprint Desktop 201518 board.May 6 2015, 11:11 AM
mollekopf closed this task as Resolved.May 12 2015, 11:07 AM