KMail dependence on Akonadi

[Nicolás Alvarez]

2017-07-11 12:47 GMT-03:00 Aleksey Midenkov <midenok at gmail.com>:
> 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.

Okay, let's change this around: What are you try to achieve with this
discussion? Having someone agree with you and rewrite the whole KDE
PIM system to not use Akonadi?

Note that as far as I know, KMail doesn't connect to IMAP servers. It
doesn't even read Maildir. akonadi_imap_resource connects to IMAP
servers, and feeds the data to the Akonadi database, and KMail reads
it from there. There is an akonadi_maildir_resource to do the same for
Maildir. KMail doesn't send email, it puts email in an Outbox folder,
akonadi_maildispatcher_agent sends email when the main akonadi daemon
notifies it that the Outbox folder changed.

-- 
Nicolás