KMail dependence on Akonadi

[Aleksey Midenkov]

On Tue, Jul 11, 2017 at 4:31 PM, Kevin Krammer <krammer at kde.org> wrote:
> On Tuesday, 2017-07-11, 16:14:18, Aleksey Midenkov wrote:
>> On Tue, Jul 11, 2017 at 2:53 PM, Kevin Krammer <krammer at kde.org> wrote:
>> > On Monday, 2017-07-10, 03:26:08, Aleksey Midenkov wrote:
>> >> On Sun, Jul 9, 2017 at 6:44 PM, Kevin Krammer <krammer at kde.org> wrote:
>> >> > On Saturday, 2017-07-08, 11:58:02, Aleksey Midenkov wrote:
>> >> >> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer <krammer at kde.org>
> wrote:
>> >> >> > On Saturday, 2017-07-08, 02:37:22, Aleksey Midenkov wrote:
>> >> ...
>> >>
>> >> >> Why you invented some
>> >> >> service if there are commonly used SQL servers?
>> >> >
>> >> > Not sure what you mean, the Akonadi services is using standard
>> >> > databases
>> >> > for its data management needs: MySQL, PostgreSQL, SQLite are options as
>> >> > far as I remember.
>> >>
>> >> Then why there is additional proxy process (Akonadi) between KMail and
>> >> DBMS? What special functions this Akonadi service does that require it
>> >> to be additional process? Why can't it be just shared library that
>> >> will adapt this PIM API (so called Akonadi) to DBMS services? In other
>> >> words: put Akonadi as shared library inside KMail, Calendar, etc.
>> >> instead of separate process.
>> >
>> > A database server is essentially useless without data and none of them can
>> > access stored data other than their own.
>> >
>> > Extending an existing database server to be able to connect to an IMAP
>> > server, read a local maildir, connect to a CalDav server or read a local
>> > ical file would essentially require forking that server's code base and
>> > maintaining it from there on.
>>
>> That surely would be bad idea. But this does not contradict to what I
>> wrote: it does not have to be a daemon. It can be just driver library
>> (like ODBC) that is loaded into client application and provides PIM
>> API to any existing data technologies, not only DBMS, but IMAP,
>> maildir, CalDav, etc. (what's the difference). So I'll repeat my
>> question: what are special functions of Akonadi that require it to be
>> additional process?
>
> I've answered that earlier but maybe it was in a reply to somebody else's
> posting.
>
> A mediator process is the only reliable way to ensure data access integrity.

I don't believe it.

>
> I.e. mechanism that try to allivate the problem of concurrent access to files
> by multiple processes , e.g. file locking, had proven to cause issues, e.g.
> stale lock files in the case of file locks.

I saw it but couldn't take serously, sorry. There are lockf(),
flock(). If you access Maildir, then you should regard other client
applications as well (since it is file-level technology), so lock
files are inevitable.

>
> There are also external restrictions to consider, e.g. maximum number of
> connections per user on a remote server. Easy to control in a single process,
> very difficult to control over multiple processes.

Difficult, but not impossible (not too difficult in fact). Seems like
you overcomplicate use cases and apply server technologies for UI
programs. Additional process for UI is a great deal: making it just
because it's straightforward to program is wrong way of doing things.

Also, you said that groupware, contacts, etc. is typical usage
scenario. Do you have some polls regarding it? F.ex. I don't use
anything but mail. AFAIK, all my acquaintances do not use even
contacts (because To: field is auto-filled when you start typing). And
frankly would someone entrust KDE for corporate usage? I would not for
sure.

>
> Akonadi is therefore the process that is needed, the DBMS is the optional one,
> e.g. using SQLite or MySQL/Embedded for handling that part inside the main
> process.
>
> Cheers,
> Kevin
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring