[Kde-pim] PIM Sprint report: Akonadi Next

[Aaron J. Seigo]

On Wednesday, November 26, 2014 14.17:41 Milian Wolff wrote:
> One question: Why flatbuffers? I'm not arguing against it, I just would like

As the others mentioned, portability is a required feature. This took 
cap'n'buffer out of the equation, unfortunately.

Even if that wasn't a blocker, we may still have elected for flatbuffers. As 
Christian noted the development seems a bit more active, which is nice. It 
also is used by a number of commercial Qt users out there and feedback is that 
it works very well, so that's one element of risk removed. There are also a 
few technical issues which also weigh in flatbuffer's favor. 

First, sanity checking buffer content is optional. This is great for when we 
are generating buffers from known data internally; we already know the data 
and it will have been sanity checked once already, such as when read from a 
local iCal file or gone through the IMAP protocol handlers. In those cases 
further checking of the buffers is just overhead. Of course, we'll want this 
when reading over the wire or from the key/value store on disk (although in 
theory we could rely on OS level security to ensure nobody can tamper with 
those files and then treat them as trusted .... there is no portable method 
for that which I know of, however.)

Also with flatbuffers fields you skip don't take space. This is nice as we'll 
probably need to pack two flatbuffers in many cases into a single value in the 
key/value store to pick up properties that the resource does not natively 
understand and therefore ignores.

.. but mostly it's the portability thing being a hard blocker.

> Interesting, thanks. Slide 17 has me worried though. How do you intend to
> make this thread/multi-process safe, when you have read/write access from
> the resource and _direct_ read access from the client?

Thread-safe, multi-process safe was a requirement for the key/value store. We 
looked at a large number of such stores and if they didn't provide this, they 
were scratched off the list immediately. So not only can we safely access the 
store from multiple processes, but also multiple threads which is just as 
important for us.

We will be able to access data from the stores in applications (KMail, etc..) 
without blocking the main thread, and we can even multithread certain access 
patterns to speed up delivery (different data sets from the same store, or 
data sets from multiple stores at once; both are common patterns in the PIM 
apps)

Thankfully, this is actually a fairly common pattern in real world problems, 
so several embedded k/v stores provide this precise feature set. Kind of funny 
to think how much the big data and web phenoms are helping us out here :)

> Why? I'm still not convinced. For the calender e.g. create a small library
> that can be used by the Plasma applet and be done with it.

If Plasma developers would be willing to write such a library, I imagine that 
would make the decision rather easier :)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141127/9cc5c25a/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/