[Kde-pim] Akonadi architectural knowledge

[Andras Mantia]

Hi,

 I wanted to write an answer, just didn't have time so far.

Morten Larsen wrote:
> 1) Drilling in from http://techbase.kde.org/Development one can end up
> at http://techbase.kde.org/Development/Architecture/KDE4/Akonadi where
> the main components of the architecture are briefly described
> (server/agents/applications).
> 
> 2) http://techbase.kde.org/Projects/PIM/Akonadi (outdated? - stops at
> Akonadi 1.4) has a little architectural in its FAQ (e.g. on the DBMS
> used) and some (unstructured) in the "Braindump".
> 
> 3) http://api.kde.org/kdesupport-api/akonadi-apidocs/ has a fairly
> detailed overview of the components of the Akonadi server (but no API
> docs - is this an error in documentation generation?).
> 
> 4) http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/index.html
> on the other hand documents client library API, but does not have any
> architecture level documentation.
> 
> 5) http://community.kde.org/KDE_PIM/Akonadi has some basic information
> on Akonadi architecture, mainly the "pie gone supernova" architecture
> diagram. There are also links to a lot of presentations on Akonadi, many
> containing architecture information and a master thesis on the server
> architecture.

You identified the resources correctly.

> Documentation on the rationales behind the architectural decisions and
> any alternatives considered are a lot harder to find. Reading through
> the meeting notes of some of the PIM meetings (esp. Osnabrück 4) you can
> find some information, including original ides and requirements.
> 
> Now for my questions:
> 
> a) Is there anything I have missed? E.g. where would I look for
> information if I wanted to interface to the Akonadi server but not use
> the client library?

hm, indeed this is not on the website. It is in the source tree though:
https://projects.kde.org/projects/kdesupport/akonadi/repository/revisions/master/changes/server/AkonadiServerProtocol.txt

We should "doxygenize" it.
 
> b) Is there a notion that someone(s) have an "architect" role in the
> Akonadi development team?

If there is, that would be Volker. He was the main man behind the Akonadi 
idea. But see below.

> c) When and how are architectural decisions made? In the meetings? In
> mailing list discussions? Other?


 AFAIK, the idea to have a central way to access and cache pim data was 
raised in one of the PIM meetings. There are usually two PIM 
meetings/sprints in a year, traditionally so far one in the beginning of the 
year and one in autumn. Plus extra meetings/sprints at the big conferences, 
like aKademy.
 Then it evolved slowly into what is now, firstly afaik was almost a one man 
project (Volker's), while others did some parts later. Discussions can 
happen in various ways. This mailing list, IRC, in-face discussions at the 
meetings. As part of the Akonadi and porting of the pim apps to Akonadi was 
done as a commercial project by KDAB and Intevation, some discussions 
naturally happened withing inter-company channels (phone, chat). As most of 
the PIM developers work for these companies, this was not really different 
from talking on freenode IRC, it was just sometimes easier to do it on other 
channels. The only difference between doing in the open or not was mainly 
about what needs to be done first and what can wait.
 Nowadays everything is going through the KDE channels.

> d) Is there an architecture review process? (I am not talking about code
> review, but design review).

No formal process. If somebody suggests architectural change, it is 
discussed. The review is for the code.

> e) Are the rationales behind architecture design decisions captured? Are
> the inputs (e.g. requirements, alternative designs) captured?

As in logged, documented? Not that I know, of course the generic 
documentations are updated as much as we have time to do it.

> f) Do you get and answer questions in the mailing list or IRC channels
> which can be considered to be architectural in nature (i.e. not on low
> level design such as detailed questions on the API)?

I'm not sure what architecture means in this context for you. The base 
architecture, how the server and clients communicate is quite set in stone, 
it is not easy to change without massively breaking stuff. So what we can 
discuss is improvements to it, and such discussions happen. Those 
improvements can be API additions, optimizations, etc. They happen from time 
to time, both on the mailing list and IRC. 
 A recent example was changing how error messages are transferred between 
client/server and how they are handled inside the server. The starting point 
was a bug, discussed on IRC, then a code suggestion (Review request), that 
was also discussed on IRC and in the review, so in the end the discussion 
and the decision happened in multiple levels.
 It resulted in introducing new API between the server and clients, so it 
can be considered an architectural change.

Andras
_______________________________________________
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/