< KDE PIMRevision as of 13:30, 12 December 2014 by Cmollekopf (talk | contribs)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) This is WIP! This is an experimental attempt at building a successor to Akonadi 1. The source code repository is currently on git.kde.org under scratch/aseigo/akonadinext Contents 1 Current Discussion Points 2 Terminology 3 Design 4 Tradeoffs/Design Decisions 5 Risks 6 Comments/Thoughts/Questions 7 Useful Resources 8 Diagrams 9 Async Library Current Discussion Points storage read API data scheme Terminology akonadi1: The current akonadi implementation on top of a SQL database akonadi-next: This is the codename for the project. In the long run this is supposed to be folded into regular akonadi, so we will never release a product called akonadi-next. Source: the canonical data set, which may be a remote IMAP server, a local iCal file, a local maildir, etc. Store: the local mirror for a given data set Syncronizer: the process responsible for modifying and synchronizing the store Resource: a set of configuration describing which syncronizer to use with what settings (e.g. server settings, local paths, etc) + a plugin for the client API to access the store. Entity: the atomic unit of a store (an email, a calendar item, a contact, a note, a tag...) Filter: a component that takes a message and performs some modification of it (e.g. changes the folder an email is in) or processes it in some way (e.g. indexes it) Pipeline: a run-time definable set of filters which are applied to a message after a resource has performed a specific kind of function on it (add, update, remove...) Query: a well-defined structure for requesting messages from one or more sources that match a given set of constraints Design Design Goals Overview Client API Resource Store Current Akonadi Legacy Akonadi Compatibility Layer Todo: the design section should eventually be split up into the other sections. Design Tradeoffs/Design Decisions Key-Value store instead of relational + Schemaless, easier to evolve - No need to fully normalize the data in order to make it queriable. And without full normalization SQL is not really useful and bad performance wise. - We need to maintain our own indexes Individual store per resource Storage format defined by resource individually - Each resource needs to define it's own schema + Resources can adjust storage format to map well on what it has to synchronize + Synchronization state can directly be embedded into messages + Individual resources could switch to another store technology + Easier maintenance + Resource is only responsible for it's own store and doesn't accidentaly break another resources store - Inter-resource moves are both more complicated and more expensive from a client perspective + Inter-resource moves become simple additions and removals from a resource perspective - No system-wide unique id per message (only resource/id tuple identifies a message uniquely) + Stores can work fully concurrently (also for writing) Indexes defined and maintained by resources - Relational queries accross resources are expensive (depending on the query perhaps not even feasible) - Each resource needs to define it's own set of indexes + Flexible design as it allows to change indexes on a per resource level + Indexes can be optimized towards resources main usecases + Indexes can be shared with the source (IMAP serverside threading) Shared domain types as common interface for client applications - yet another abstraction layer that requires translation to other layers and maintenance + decoupling of domain logic from data access + allows to evolve types according to needs (not coupled to specific applicatoins domain types) Risks key-value store does not perform with large amounts of data query performance is not sufficient turnaround time for modifications is too high to feel responsive design turns out similarly complex as akonadi1 Comments/Thoughts/Questions Comments/Thoughts: Copying of domain objects may defeat mmapped buffers if individual properties get copied (all data is read from disk). We have to make sure only the pointer gets copied. Open Questions: Resource-to-resource moves (e.g. expiring mail from an imap folder to a local folder) Should the "source" resource become a client to the other resource, and drive the process? This would allow greatest atomicity. It does imply being able to issue cross-resource move commands. If we use the mmapped buffers to avoid having a property level query API, lazy loading of properties becomes difficult. Currently we specify how much of each item we need using the parts, allowing the lazy loading to fetch missing parts. If we no longer specify what we want we cannot lazy load that part and at the point where the buffer is accessed it's already too late. How well can we free up memory with mmapped buffers? 1000 objects are loaded with minimal access (subject) A bunch of attachments are opened => we stream each file to tmp disk and open it. Can we unload the no-longer required attachments? => I suppose we'd have to munmap the buffer and mmap it again, replacing the pointer. This may mean we require a shared wrapper for the pointer so we can replace the pointer everywhere it's used. Datastreaming: It seems with the current message model it is not possible for the resource to stream large payload's directly to disk. As a possible solution a resource could decide to store large payloads externally, stream directly to disk, and then pass a message containing the file location to the system. How do we deal with mass insertions? => n inserted entities should not result in n update notifications with n updates. I suppose simple event compression should largely solve this issue. Potential Features: Undo framework: Application sessions keep data around for long enough that we can rollback to earlier states of the store. Note that this would need to work accross stores. iTip handling in form of a filter? i.e. a kolab resource could install a filter that automatically dispatches iTip invitations based on the events stored. Thoughts from Meeting (till, dvratil, ...) that need to be processed: Notification hints (what changed), to avoid potentially expensive updates for minor changes. (Only hints though, not authorative changeset, can be optimized for usecases). Resorting in kmail is a common operation New S/MIME implementation that doesn't support all of PGP would probably suffice DVD by email case should be considered Hierarchical configuration. Fallback to systemconfig. Reupload messages we failed to upload should be possible IMAP Idle => we cannot shutdown the resources Migration is important (especially pop3 archives, as they cannot redownload) Optional Akonadi would be nice (If you have a 100MB quota you may not have 50MB for akonadi). For pipelines: i.e. for mail filter we must guarantee that a message is never processed by the same filter twice. Do we need i.e. a shared Node/Collection basetype for hierarchies, so we can i.e. query the kolab foldertree containing calendars/notebooks/mailfolders. Useful Resources Socket activated processes (for the resource shell): http://0pointer.de/blog/projects/socket-activation.html PIM Sprint presentation: http://bddf.ca/~aseigo/akonadi_2015.odp Diagrams Akonadi Next Workflow Draft Async Library Problem with std::future: Only synchronous waiting on result. Proposal for std::future with continuations: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3721.pdf Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/Akonadi_Next&oldid=40845" Content is available under Creative Commons License SA 4.0 unless otherwise noted.