KMail dependence on Akonadi

[Kevin Krammer]

On Tuesday, 2017-07-11, 18:47:57, Aleksey Midenkov wrote:
> 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.

Unfortunately it is.

> > 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().

From the API point of view this is mostly fine, but not necessarily from the 
runtime perspective.

File locking depends a lot on the file system, the super nice options might not 
be available.
The old contact/calendar system which worked with file locking rather than 
single process access needed to support, if I remember correctly, 3 different 
mechanisms due to the wide range of capabilities on the users' systems.

Remotely mounted filesystems such as NFS or SMB are particularily problematic.

> If you access Maildir, then you should regard other client
> applications as well (since it is file-level technology), so lock
> files are inevitable.

Maildir itself is easy, since mails are never modified.
The directories only need to be monitored for files being created or being 
deleted.

Other data types of storage backends are more problematic.

Additionally to the data there is then also the access to index/cache 
information, because it is not viable to parse lots of files over and over 
again, e.g. when changing a folder.

And that data is more rapidly changing then user data.

> > 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).

Without an arbiter that is not easy at all.

A program would basically need to acquire some lock for a certain address/port 
combination and a mechanism to be notified if the lock becomes available.
And that is the simple case of restricting to one connection.

> 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.

For a single program that is true, but as explained earlier this is not the 
single data silo program use case.

> Also, you said that groupware, contacts, etc. is typical usage
> scenario.

You should see how often people ask for the status of Exchange support.

> 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).

Sure, nowadays people might only use their phone for contacts and calendaring, 
but those who do that on their PC would likely want to continue doing that, 
no?

> And
> frankly would someone entrust KDE for corporate usage? I would not for
> sure.

Interestingly a lot of the groupware features in KDE PIM have been done as 
contract work for German government institutions.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20170719/64ced130/attachment.sig>