Re: 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  wrote:
> > On Tuesday, 2017-07-11, 16:14:18, Aleksey Midenkov wrote:
> >> On Tue, Jul 11, 2017 at 2:53 PM, Kevin Krammer  wrote:
> >> > On Monday, 2017-07-10, 03:26:08, Aleksey Midenkov wrote:
> >> >> On Sun, Jul 9, 2017 at 6:44 PM, Kevin Krammer  wrote:
> >> >> > On Saturday, 2017-07-08, 11:58:02, Aleksey Midenkov wrote:
> >> >> >> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer 
> > 
> > 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 

Re: KMail dependence on Akonadi

[Leslie Turriff]

On 2017-07-17 18:29:29 Aleksey Midenkov wrote:
> Another problem is too little feedback, so devs are on their own. 999
> of 1000 are just silently choose what to use. When you ask them they
> will tell you their reasons, but they will never tell it on their own.

I've tried to get changes through various bug systems; the response has 
almost always been 'I think the way it is, is best, so I won't change it'.  
When I tried to get the supporter of USB2TTY to change his hard-coded device 
names to dynamic ones so that I could connect a tty device using the name its 
software wanted, I was told, 'nobody uses this, so I'm not changing it.'

Re: KMail dependence on Akonadi

[Aleksey Midenkov]

On Tue, Jul 18, 2017 at 1:46 AM, Leslie Turriff  wrote:
> On 2017-07-11 21:44:31 Nicolás Alvarez wrote:
>> 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
>
> Of course, those of us who object to having Akonadi's fingers in 
> their Kmail
> can do what I did and revert to KDE3, with it's friendly user interfaces and
> straightforward Kmail.

Or we can try talk some sense into people. There is big dispersion in
development, everybody does what he wants. So no decent quality ever.
KDE3 is one half working and KDE4+ is the other half working.
Microsoft is 3rd half-working. OSX is 4th half-working. Android have
taken big portion of developers. I didn't expect such dull and dumb
future. What an irony: great hardware running crippled and miserable
programs. Maybe the time have not come yet...

Another problem is too little feedback, so devs are on their own. 999
of 1000 are just silently choose what to use. When you ask them they
will tell you their reasons, but they will never tell it on their own.

>
> Leslie

Re: KMail dependence on Akonadi

[Nicolás Alvarez]

2017-07-11 12:47 GMT-03:00 Aleksey Midenkov :
> On Tue, Jul 11, 2017 at 4:31 PM, Kevin Krammer  wrote:
>> On Tuesday, 2017-07-11, 16:14:18, Aleksey Midenkov wrote:
>>> On Tue, Jul 11, 2017 at 2:53 PM, Kevin Krammer  wrote:
>>> > On Monday, 2017-07-10, 03:26:08, Aleksey Midenkov wrote:
>>> >> On Sun, Jul 9, 2017 at 6:44 PM, Kevin Krammer  wrote:
>>> >> > On Saturday, 2017-07-08, 11:58:02, Aleksey Midenkov wrote:
>>> >> >> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer 
>> 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

Re: KMail dependence on Akonadi

[Aleksey Midenkov]

On Tue, Jul 11, 2017 at 4:31 PM, Kevin Krammer  wrote:
> On Tuesday, 2017-07-11, 16:14:18, Aleksey Midenkov wrote:
>> On Tue, Jul 11, 2017 at 2:53 PM, Kevin Krammer  wrote:
>> > On Monday, 2017-07-10, 03:26:08, Aleksey Midenkov wrote:
>> >> On Sun, Jul 9, 2017 at 6:44 PM, Kevin Krammer  wrote:
>> >> > On Saturday, 2017-07-08, 11:58:02, Aleksey Midenkov wrote:
>> >> >> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer 
> 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

Re: KMail dependence on Akonadi

[Kevin Krammer]

On Tuesday, 2017-07-11, 16:14:18, Aleksey Midenkov wrote:
> On Tue, Jul 11, 2017 at 2:53 PM, Kevin Krammer  wrote:
> > On Monday, 2017-07-10, 03:26:08, Aleksey Midenkov wrote:
> >> On Sun, Jul 9, 2017 at 6:44 PM, Kevin Krammer  wrote:
> >> > On Saturday, 2017-07-08, 11:58:02, Aleksey Midenkov wrote:
> >> >> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer  
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.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.

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.

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


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

Re: KMail dependence on Akonadi

[Aleksey Midenkov]

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

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

Re: KMail dependence on Akonadi

[Kevin Krammer]

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


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

Re: KMail dependence on Akonadi

[Leslie Turriff]

On 2017-07-08 01:14:49 Duncan wrote:
> You may be confusing akonadi and nepomuk/baloo.

Okay, you're right.  But they're both more trouble than they're worth.

Re: KMail dependence on Akonadi

[Kevin Krammer]

On Saturday, 2017-07-08, 11:58:02, Aleksey Midenkov wrote:
> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer  wrote:
> > On Saturday, 2017-07-08, 02:37:22, Aleksey Midenkov wrote:
> >> By what purpose there is KMail dependence on other services?
> > 
> > The purpose if the dependency is to make KMail work.
> > I.e. in order for KMail to display or send emails it needs to access
> > emails.
> Can't it work via shared library, e.g. SQLite or some NoSQL technologies?

I am not sure what you are referring to, but the programs all use a shared 
library to implement the communication with the service.

That way each client doesn't need to know too much about how everything works, 
for them it is a tree of folders and data in folders, e.g. emails in email 
folders.

> > Access to data such as emails, contacts, calendar, etc., is shared between
> > applications through the Akonadi service (PIM data, personal information
> > management).
> 
> Is it common case? I mean are there many people who use contacts,
> calendar (what else?). Or there are majority who just use e-mail.

It is a very common use case.

Theoretically an email program could always just do input completion on 
addresses of people that it has received emails from, but most have an 
addressbook nevertheless.

Thunderbird even has a calendar extension called Lightning.

Contacts/addressbook are also used by other forms of communcation programs, 
e.g. chat, software telephone, audio/video conferencing.

Additionally, as mentioned before, work related tasks, such as invoicing, 
mailing (as in post mail) and things like that.
Aside from businesses, users can have these kind of work loads for 
foundations, clubs, fan associations, etc.

I.e. quite common when groups of people do stuff together :-)

> Can't data be shared via dynamic library API? AFAIK no-server
> databases can support multi-process R/W access.

Exactly.
The safest, most trouble free, way of accessing stored data is via a single 
process.
Mutiple processes accessing e.g. the same files or directories can be done via 
a wide range of file locking mechanisms, but they are all problematic, depend 
on the file system in question.

Data gets easily overwritten (two processes thinking they have the lock) or 
not writable anymore (stale locks).

An earlier version of PIM data sharing used that approach and it was messy.

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

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


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

Re: KMail dependence on Akonadi

[Nicolás Alvarez]

2017-07-08 5:58 GMT-03:00 Aleksey Midenkov :
> On Sat, Jul 8, 2017 at 11:34 AM, Kevin Krammer  wrote:
>> On Saturday, 2017-07-08, 02:37:22, Aleksey Midenkov wrote:
>>> By what purpose there is KMail dependence on other services?
>>
>> The purpose if the dependency is to make KMail work.
>> I.e. in order for KMail to display or send emails it needs to access emails.
>
> Can't it work via shared library, e.g. SQLite or some NoSQL technologies?

Akonadi can use SQLite instead of MySQL, but it's not well-supported,
and you still need the Akonadi daemons running anyway.

Under the hood, the current version of KMail *is* a frontend to the
email features of Akonadi. Even interaction with mail servers is done
by one of Akonadi's daemons, not by the KMail process.

-- 
Nicolás

Re: KMail dependence on Akonadi

[Kevin Krammer]

On Saturday, 2017-07-08, 02:37:22, Aleksey Midenkov wrote:
> By what purpose there is KMail dependence on other services?

The purpose if the dependency is to make KMail work.
I.e. in order for KMail to display or send emails it needs to access emails.

Access to data such as emails, contacts, calendar, etc., is shared between 
applications through the Akonadi service (PIM data, personal information 
management).

E.g. for an email program like KMail it doen't matter whether an email folder 
is stored locally or on an IMAP server, it just requests the folder's contents 
from the service.

Such all email programs can access the same data cooperatively.

Same obviously applies for addressbooks, calendars, etc. [1]

In short it is a system allowing PIM data to be share between applications, 
without requiring users to run their own groupware server like Kolab or 
Exchange.

Similar approaches are used by GNOME [2] and mobile platforms [3].

> Can it work standalone?

For a standalone data silo approach you can, for email, have a look at 
Thunderbird, Claws and many others.

Cheers,
Kevin

[1] Access to PIM data is not necessarily just interesting for PIM user 
programs. An invoicing application could access the addressbook, create and 
send an email with the invoice and add a calendar entry with a reminder to 
check for payment.

It allows specialized programs to only work on a subset of data. E.g. 
https://zanshin.kde.org/ is specialized on handling TODOs but a user still has 
access to those TODOs through a traditional calendaring application, e.g. 
KOrganizer.

[2] Evolution Data Server, EDS

[3] Mobile platforms such as Android, iOS, etc., also handle PIM accounts 
centrally via the platform's PIM service. Different apps, depending on the 
user's choice on access rights, then access that data independent of which 
account it came from.

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


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

Re: KMail dependence on Akonadi

[Duncan]

Leslie Turriff posted on Fri, 07 Jul 2017 23:01:57 -0500 as excerpted:

> On 2017-07-07 18:37:22 Aleksey Midenkov wrote:
>> By what purpose there is KMail dependence on other services? Can it
>> work standalone?
> 
> Based on the responses that I saw during the rollout of KDE4 and the
> confusion that Akonadi caused, the KDE developers think that Akonadi is
> a wonderful tool that should be connected to every other component of
> KDE, whether or not that makes sense, and regardless of any adverse
> impacts that it causes.  I believe that eventually the community was
> able to convince them to put in some sort of mechanism for disabling
> Akonadi, but I'm not sure that doing so does not in some ways cripple
> the parts of KDE (e.g. Kmail) that depend on it.  Akonadi is one of the
> major new "features" that have caused me to retain KDE3 as my desktop.

You may be confusing akonadi and nepomuk/baloo.

FWIW, akonadi is a database-backend specific to kdepim and its component 
applications.  It's what now handles contact information such as email 
addresses, IRC handles, phone numbers, IM addresses, etc, and by now it's 
a mandatory dependency of pretty much anything kdepim related.

*BUT*, the dependency is limited to kdepim.

*HOWEVER*, kmail is a kdepim component, so, unfortunately, requires 
akonadi.

In theory, akonadi is a kdepim shared service, and the kdepim developers 
like it because individual apps don't have to write all the contact 
handling code for each app, they simply write to the akonadi interface 
and let it take care of the rest of the backend.

And in theory, users should like it for two reasons: One, because they 
devs don't have to write and rewrite the functionality for multiple apps, 
they should have more time to do other "nice things", bugfix or implement 
fancy new features that they'd not have time to do if they were spending 
it maintaining their individual contact information code.  Two, with the 
shared backend, a single contact can be entered once, and it will appear 
in all the various kdepim apps, kmail, the irc client, the IM client, 
etc, with a reasonably common and thus familiar GUI, learn the contact 
management GUI once and you should know it for the entire kdepim family 
of apps.

Unfortunately, akonadi as a database backend data handler has been 
demonstrated to be rather less than stable for many users, to crash 
frequently, and to rather frustratingly lose data, messages, etc.  Often, 
the appropriate database-rebuild incantation can bring them back, but...

In my case, some time ago I asked myself why I was putting up with it.  
Email isn't rocket science, tho it has been around since rocket 
scientists were walking on the moon, and by now it's stable technology 
with time-proven techniques for managing it without crashing, without 
losing messages, and while staying relatively fast.

After asking myself that I realized there wasn't a good answer, so soon 
enough I WASN'T putting up with it, and had switched to a much more 
stable email app.

In my case I chose claws-mail, replacing both kmail and akregator (the 
kdepim-based feed-reader) with it, and I've been very happy.  But I've 
known others that went with Thunderbird or Evolution.  (Those weren't 
good choices for me for several reasons, including that they use 
databases too, altho their database usage seems to be more stable, 
evolution being a gnome client and bringing in way more gnome deps than I 
wanted, and both of them being HTML-based mail clients, while I prefer a 
mail client that doesn't do HTML by default, for security reasons.)

That's akonadi, limited to kdepim but mandatory there, the reason I don't 
have anything kdepim related on my system, any longer.

Nepomuk/baloo, meanwhile, is a general purpose file-indexer, of course 
with its own database storing the results so they're instantly 
available.  Baloo is the current incarnation, replacing the nepomuk from 
early kde4 in late kde4.

So this is entirely different.  Baloo is /not/ mandatory for most of kde, 
tho it is for a few small componenents, but the option to support it or 
not is normally a build-time option, choosing to link in the library for 
that support, or not, and most binary distros enable it by default, 
making it mandatory for their kde packages as they're normally linked 
against it and thus won't run without it.

It's possible there's a few "kde-lite" binary distros that disable baloo 
at build time, but meanwhile, even if it's enabled at build-time and 
installation is thus mandatory, it can be turned off, tho a few functions 
it provides then become unavailable.

For source-based distros such as gentoo, meanwhile, baloo can be an 
option, as it is for gentoo's kde/plasma, controlled by the semantic-
desktop USE flag.  FWIW I'm a gentooer, and I have the option disabled 
here, so my kde/plasma is built without baloo, and my system doesn't have 
it installed at all.  Because I built without baloo in the first place, 

Re: KMail dependence on Akonadi

[Leslie Turriff]

On 2017-07-07 18:37:22 Aleksey Midenkov wrote:
> By what purpose there is KMail dependence on other services? Can it
> work standalone?

Based on the responses that I saw during the rollout of KDE4 and the 
confusion that Akonadi caused, the KDE developers think that Akonadi is a 
wonderful tool that should be connected to every other component of KDE, 
whether or not that makes sense, and regardless of any adverse impacts that 
it causes.  I believe that eventually the community was able to convince them 
to put in some sort of mechanism for disabling Akonadi, but I'm not sure that 
doing so does not in some ways cripple the parts of KDE (e.g. Kmail) that 
depend on it.  Akonadi is one of the major new "features" that have caused me 
to retain KDE3 as my desktop.