Akademy 2014 - KDE PIM BoF Notes

Agenda

KF5
Vishonadi/Christianonadi/Danonadi
KPeople
Acceptance Testing
Toulouse Student Projects

KF5 Split

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
kpimutils
- 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

Akonadi Changes

Christian's plans:

abandon content agnostic design, hard code type support in the server, allowing some content queries on the server

Dan's plan:

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?

Vishesh's plan:

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

Kevin's plan:

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.