KDE PIM/Meetings/Osnabrueck 4/Architecture

Osnabrück Meeting Notes, Saturday 7 January 2006, afternoon session

Architecture Meeting

Dramatis Personae

• AG: Andreas Gungl
• CS: Cornelius Schumacher
• IK: Ingo Klöcker
• MB: Michael Brade
• MM: Marc Mutz
• RK: Reinhold Kainhofer
• TA: Till Adam
• TK: Tobias König
• VK: Volker Krause
• WS: Will Stephenson

Layers

Architecture diagram

• Storage layer with caches, mailserver, XML db, maildir?
  • Storage access protocol, IMAP, http, dbus?
    • APIs - libraries provide access as C++ objects or whatever
    • KDE API
      • KResources
        • iCal flat file
        • OX
        • GroupWise
      • KDE Clients
        • Kontact
        • KOffice
    • GNOME API
      • EDS
        • Evolution
    • MUTT API
    • OTHER APIs

Notes

Layered Architecture of Akonadi

Difference to previous system: Only one API to access storage whether clients or resources. Resources can still run out of process.

We should keep in mind that the storage backend may need to be replaced and provide some level of abstraction to support it.

TK: Caching policies: how will we define when to write local cached changes back to a remote server?

MM, TA: should resources and clients share same API? MM says that resources and clients access storage in different modes. clients initiate all actions. even change notifications are just triggers that cause a client to initiate a read. CS says that one protocol for both sides of the clients/resources is more symmetrical and elegant, and that one storage access protocol implies one library based client protocol

Implementation

Assumptions are that Storage Access Protocol and Storage Layer will be a relational database accessed via a IMAP mail server

WS: are we considering the small memory case - do we run the danger of getting a system limited to trad desktops/laptops? CS: this is the reason for keeping abstraction that would allow you to use filesystem as storage, discarding caching and some features, maybe with sqlite for indexing

An alternative implementation could be an xml database accessed over http...

Crypto: how do we approach storing and indexing encrypted mails - we would want to access parts of mails in order to index

How will we implement other actions not related to data eg setting GW prefs? Again, resource specific config needed.

How do we handle unimplimented-by-a-server features? Do we disable the GUI, or cache locally and not write to server?

How do we notify events - use a UI server? What about non KDE UI - DBUS? The server should be able to work outside X, but do we notify text based clients?

What about querying? Do we have an external indexing service that is accessed transparently to query for specific items, then the we ask the actual storage and it returns those items? For reasons of storage simplicity, make it possible to index externally, makes implementation simpler and allows different sized impls of the system.

WS We need to be able to perform queries in the resources in the case of very large data sets that cannot be loaded entirely into storage. TA, MM agree that need to turn local queries into imap queries and pass thru to imap server. (likewise for GW)

What will the criteria to choose a storage layer? Performance, licensing, do we like the code, do we like the authors?

• EDS
• Oryx
• XML + http + XQuery

TA: We should start with the outer edge of the KDE API. If we do that right everything below can be decided later. Project for the rest of the meeting is to start on an API.

AG: thinks the storage access protocol is more important

TA: We should work together with Evolution.