Architecture/planning/evolution-data-server

Revision as of 11:05, 4 April 2011

Introduction

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) was announced publicly on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is Patrick Ohly. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

Calendar Storage

Maemo solution: QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage)
EDS proposal: QtMobility/QtOrganizer (API) + /KCalCore-EDS + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file)
Used by: calendar app (Sirisha Muppavarapu), clock app (originally Todd Brandt)

Advantages of mKCal:

• partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
• incremental changes to database; EDS must rewrite complete file

Disadvantages of mKCal (current implementation):

• only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:

• use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd())
• write storage which uses libecal/EDS
• EDS improvements

Contact Storage

Maemo solution: QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker)
EDS proposal: QtContacts (API) + [[Architecture/planning/evolution-data-server/QtContacts storage plugin|QtContacts-EDS] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd
Used by: libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml (Connie Berardi and [1]), SMS and Messaging apps (Ben Drucker), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin)

Advantages of Tracker:

• supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
• better searching
• scalability (?)
• read performance (?)

Disadvantages of Tracker:

• data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
• slow write performance in QtContacts-Tracker (?)

Plan:

• write a QtContacts storage plugin (details on QtContacts-EDS),
• EDS improvements
• libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

Opens:

• obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
• communication history, currently done with QSettings in dialer app - how will that be done in the future?

Mail Storage and Transports

Maemo solution: QtMobility/QtMessaging API + Qt Messaging Framework (QMF, actual implementation)
EDS: QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet)
Used by: mail app (Carl Wong), SMS storage plugin (Ben Drucker)

Advantages of QMF:

• already works as a stand-alone daemon

Plan A (details)

• kudos to Srinivasa (Srini) Venkateswaran for this proposal
• write simplistic server which runs Camel
• replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps requires recompilation, not rewriting)
• account setup UI

Plan B:

• keep QMF as mail infrastructure

Data Synchronization

Maemo solution: Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP)
Alternative: SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol

Advantages of Buteo:

• plugable sync engines, more sophisticated scheduling of time-based syncs
• Tablet Google Contact sync preserves properties not supported by Google

Disadvantages of Buteo:

• incomplete, untested (in MeeGo)
• no support for incoming SyncML over OBEX/Bluetooth

Step 1:

• keep Buteo Sync Framework
• replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
  • The existing Buteo sync plugin must also support Google Contacts. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
  • Preserving local extensions when synchronizing with Google depends on hard-coding capabilities of that peer and support for unknown properties.
  • Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must replace global variables.

Step 2:

• rewrite QML settings backend to use SyncEvolution D-Bus API
• remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

Further improvements to SyncEvolution/MTP:

• code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
• support push sync
• redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
• device-to-device sync over WLAN
• MTP over WLAN and Bluetooth