< KDE PIM | Meetings | Osnabrueck 4 Revision as of 21:01, 26 February 2011 (view source)Mahoutsukai (talk | contribs) (add information from Osnabrueck 4) Latest revision as of 20:54, 27 February 2011 (view source) Mahoutsukai (talk | contribs) m Line 19: Line 19: === Layers === === Layers === −[[Image:KDE_PIM_Meeting_Osnabrueck_4_Architecture_Diagram.jpg|center|512px|alt=Architecture diagram of Akonadi|Architecture diagram]]+[[Image:KDE_PIM_Meeting_Osnabrueck_4_Architecture_Diagram.jpg|center|560px|alt=Architecture diagram of Akonadi|Architecture diagram]] * <span style="color:blue;">Storage layer with caches, mailserver, XML db, maildir?</span> * <span style="color:blue;">Storage layer with caches, mailserver, XML db, maildir?</span> Latest revision as of 20:54, 27 February 2011 Osnabrück Meeting Notes, Saturday 7 January 2006, afternoon session Contents 1 Architecture Meeting 1.1 Dramatis Personae 1.2 Layers 1.3 Notes 1.4 Implementation 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 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 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. Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/Meetings/Osnabrueck_4/Architecture&oldid=10447" This page was last edited on 27 February 2011, at 20:54. Content is available under Creative Commons License SA 4.0 unless otherwise noted.