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!