Akademy 2014 - KDE PIM BoF Notes
- Acceptance Testing
- Toulouse Student Projects
Laurent wanted to split based on current directory structure and all it once.
Do we want to do more core/ui split? KF5 Frameworks can contain multiple libraries per framework, so this isn't necessarily a requirement.
Split at once or split one by one?
- split in one go once nothing has to be moved anymore, but move to "proper" frameworks one by one, to have a few new frameworks in every KF5 release
- problem: we also want to merge Akonadi client lib into server repo: first split client lib into its own repo, then merge (how exactly? Aleix, Nicolas and Alex Merry know)
Keep history or git graft? Keep kdepimlibs.git and connect to it via git graft
Due to split at once, we need to sort stuff into correct frameworks first.
- there are some obvious ones, like kabc (possibly rename), kcalcore (rename?), kimap, kxmlrpc, etc
- remove the dumping grounds - kpimutils
- merge gpgme++ and qgpgme
- kill microblog
- kill akonadi-abc
- better name for kcalutils
- kpimtextedit: split and merge with ktextwidgets and/or application?
- depends on KMime, XMLGUI, Sonnet
- HtmlHighlighter - replace with Kate
- needs in-depth analysis, ideally completely dissolved into other frameworks and applications
- emoticons and rich text stuff could go to ktextwidgets
- ProgrssIndicator* only used in two place in kdepim, could move there for now
- needs a solution for email*, either merge into kmime or kcoreaddons (with moving a few decoders there)
- try to get data type libraries (kcal, kabc, kmime) tier 1
- Akoandi client library depends at least on a few tier 1s for its core library
Timeline: some frameworks are basically ready (xmlrpc, syndication, holidays) but some need more work
- abandon content agnostic design, hard code type support in the server, allowing some content queries on the server
- tighter integration between client and server
- use the pre-processor for more stuff, after fixing it, but there are concerns about the possible delays it introduces
- abandon text and D-Bus based protocol in KF5, protocol would be purely internal (there are some concerns on bindings and different client implementation, OTOH that hasn't happened in the past 10 years)
- effectively prevents co-installability of KDE4 applications and KF5
- command out of order execution
- cancelable queries
- change default SQL database?
- tighter integration between Baloo and Akonadi server, integrate indexer as part of the resource
- solves indexing of maildir
- fixes the delayed indexing problem that the pre-processor also addresses
- main cost of indexing was parsing and transfer, which would go away this way
- search would be delegated to resources, and results being merged by the server, but slightly higher I/O due to distributed search
- concern: too high disk I/O due to parallel indexing
- variation of this:
- xapian db managed by Akonadi server, but indexers stay on resource side
- indexed documents go over the protocol, which is acceptable cost-wise
- per-mimetype xapian tables
- Akonadi server can query xapian locally
- direct xapian access possible
- contact completion probably out of band in its own database, containing all known names/emails
- job-based resource infrastructure
Mail threading and iCal recurrence continue to be a problem for queries. Possible solution store thread or recurrence interval that contains all relevant items, and query on that, gives you too much data, but still a massively smaller subset
Sort out at Akonadi sprint?
Timeline: Dan says 0.5 - 1 year for the Akonadi changes
Toulouse Student Program
Kevin O. wants tasks and mentors, the program continues. Teams of 3-5 students, for about 5 months. Needs about 4-6 goals and two mentors each, by the end of next week!
- Akregator port (Alex, Dan), just storage missing
- KMail/Kontact Active? (Michael, Kevin K)
- Global email search, and statistics? (Vishesh, Christian)
- Social media integration (Martin, David)
KDE Connect Integration
Someone is working on calendar integration, but not present here.