[Kde-pim] KDE PIM Sprint summary

[Daniel Vrátil]

Hi all,

this is a "short" summary of some things we discussed on the sprint.  You can 
find a full record of all that was discussed here [0]. 

* Calendar events envelopes
Extract DTSTART, DTEND, precalculated end of recurrence (if any), whether the 
event has alarm, and subject into PLD:ENVELOPE part, so that calendar 
applications can optimize the amount of events stored in memory. For example 
KOrgac could only fetch full payload of events that have an alarm and drop all 
other items from memory.

* Capabilities for Resources ("Storage Capabilities")
Have a standardized set of capabilities for each mime type that indicate what 
all information a Resource can store in it's storage backend. Client 
applications would then disable parts of their UI based on that. For example 
Google does not support storing priorities and progress for Todos. Incidence 
Editor would disable these fields when creating a new task in a Todo list 
owned by the Google Resource.

* Items Relations
Items relations are named relations between two Items. It is needed primarily 
by Kolab for attaching notes to emails, but other usecases can be found. 
Internally we would have RelationTable (leftPimItem (INT), relationTypeId (INT 
FK RelationTypeTable.id), rightPimItem (INT)) and RelationTypeTable (id (INT), 
name (VARCHAR)). Relations don't have IDs, but they are uniquely identified by 
the touple (left side, name, right side).

* Items Groups
Items groups allow clients to easily obtain a subset of items based on certain 
criteria, that is otherwise unknown to Akonadi server. For events there can be 
one group for each month, so KOrganizer would only request items belonging to 
a group representing the currently displayed month. For emails each thread 
could be a group, so that KMail could only request several groups and then 
perform threading on these groups in parallel, which would massively speed up 
opening a folder.

* Job-based Agents
An idea that Christian came up with. I am absolutely *thrilled* by it and I 
expect we follow up on it during Akademy (or maybe before). The idea is that 
instead of having AgentBase::Observer with methods for each type of task that 
resource has to implement, we would have a set of Jobs, like RetrieveItemsJob, 
ItemChangedJob, ItemAddedJob, etc. which resources would reimplement and then 
register to ResourceBase. Registered jobs implementations == set of tasks the 
resource supports (so we don't have to add a new Observer class every time 
want to add a new notification). ResourceBase would simply dispatch a Job for 
each task and wait for it to finish.  In the long term, we could even modify 
ResourceScheduler to be able to handle multiple jobs in parallel! 

Jobs are a very nice pattern for encapsulating asynchronous operations, which 
is exactly what resources do, and it would not just reduce the amount of 
random subtle bugs in resources, but would also make the code much much easier 
to read. IMAP resource is a great example of this approach and evidently it 
works very well.

* Removing SELECT command
CollectionSelectJob is currently used only by ItemFetchJob and ItemDeleteJob 
and the current implementation of CollectionSelectJob only allows SELECT 
SILENT, so it never provides collection statistics (which is the only actually 
useful thing on SELECT). This puts SELECT on the same level as doing

UID FETCH COLLECTION ID 42 1:*

ID is necessary because SELECT also supports RID, so we need to support it 
too. The main difference between this approach and the SELECT one is, that it 
saves us one command to run before every FETCH, which should speed it up a 
bit. Also, it allows us to introduce an alternative to collection context, 
which is a tag context:

UID FETCH TAG 42 1:*

Fetches all items tagged with ID 42 (which Christian and Kevin need for 
Zanshin) or even a combination of both:

UID FETCH COLLECTION ID 42 TAG 10 100:105

which fetches items with IDs 100 - 105 from collection 42 tagged with tag 10.





[0] https://notes.kde.org/p/kdepim-sprint-2014

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140401/71ca6653/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/