Re: KMail dependence on Akonadi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday, 2017-07-10, 03:26:08, Aleksey Midenkov wrote:
> On Sun, Jul 9, 2017 at 6:44 PM, Kevin Krammer <krammer@xxxxxxx> wrote:
> > On Saturday, 2017-07-08, 11:58:02, Aleksey Midenkov wrote:
> >> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer <krammer@xxxxxxx> 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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux