Bug 289342

so, following your logic, you should also:
- stop cups when you don't need it,
- stop the firewall when you don't need it,
- stop udev when you don't need it 

and so on for every service ?

I don't think the comparison is quite fair.  Certainly the latter two of those that you mention provide essential system services that need to operate regardless of what the user is doing - or even when no user is logged in.  It could be argued that CUPS could stop when idle - but it needs to run as root in order to perform some of its functions and therefore there may be problems in starting/stopping it on user demand.

Akonadi, on the other hand, requires no privileges and provides access to the user's data (whether local or remote) at the user's request when using PIM applications (the Plasma calendar counts as one of those).  If the user is not using the application, there is no need for Akonadi to remain active, and there could even be data integrity problems if it continues to access the data or remote resources even when the user is not expecting it to.  In my example of continuing to access POP3 mail after KMail has exited, this could lead to emails being fetched and stored where the user is not expecting them to go - which is only a step away from data loss.

On the question of the system resources used by Akonadi this is surely not the first time that this has been raised, but just for illustration:

akonadi_control				1.0M
mysqld					46.1M
akonadiserver				3.4M
akonadi_agent_launcher			2.6M
akonadi_kdeaccounts_resource		9.3M
akonadi_agent_launcher			4.6M
akonadi_maildispatcher_agent		4.4M
akonadi_mailfilter_agent		5.7M
akonadi_pop3_resource			8.2M
akonadi_vcarddir_resource		3.0M

cupsd					912K

(Reported by KDE System Activity in the "Mem" column.  No PIM applications running, KMail configured for Local Folders + 1 POP3 fetch, KAddressBook with 2 resources, Nepomuk Email Indexer turned off.  So Akonadi is using nearly 100 times the memory of CUPS.)

Please be a bit more polite here, we are all trying to improve KDE and Akonadi to gain more market share.

I'm actually agreeing with Jonathan that this makes sense as we'd only like these services to be available when we - the user - demand them to. Let's not forget the user perspective in here, that doesn't know what "Akonadi" is and - as being a humble user - shouldn't know about it. Akonadi is a background service that facilitates the user indirectly and therefore should be gaining less to no direct attention - even not in unexpected system resources.

Adding a "auto shutdown" feature would be very appreciated - and I think I speak on behalf of many KDE users - and even does it when it's optional.

Niels
(In reply to comment #1)
> so, following your logic, you should also:
> - stop cups when you don't need it,
> - stop the firewall when you don't need it,
> - stop udev when you don't need it 
> 
> and so on for every service ?

(In reply to comment #3)
> Please be a bit more polite here, we are all trying to improve KDE and
> Akonadi to gain more market share.

We'll survive without this kind of useless advices.

> 
> I'm actually agreeing with Jonathan that this makes sense as we'd only like
> these services to be available when we - the user - demand them to. 

Thanks, that's *exactly* why the resources and consequently the Akonadi server are not stopped: to be available when the user needs them.

> Let's
> not forget the user perspective in here, that doesn't know what "Akonadi" is
> and - as being a humble user - shouldn't know about it. Akonadi is a
> background service that facilitates the user indirectly and therefore should
> be gaining less to no direct attention - even not in unexpected system
> resources.

Unrelated

> Adding a "auto shutdown" feature would be very appreciated - and I think I
> speak on behalf of many KDE users - and even does it when it's optional.
> 
No, you speak on *your* behalf

I'm voting for this.

*** Bug 412240 has been marked as a duplicate of this bug. ***