Let the user decide if in doubt

(or: stop services that are not needed by any client)

If it comes to decisions there is always the aim to just do the right thing. In a lot of cases there is the one right thing. In quite a few cases there is no right thing but the consequences are small enough that it does not really matter which decision one takes. And then there are those use-cases where the only right thing to do is to ask the user because any other decision would just be guessing and lead to RAM and CPU wasting.

Yet even in the latter situations some apps are too lazy to ask the user or even claim that not asking the user – not even once – is the best solution – and even more astonishing: for the user’s good. So basically they claim to be smarter than the user or just do not care about the user’s resources or opinion.

Akonadi

In case akonadi is not running when the user starts kmail (and this example is only about that use-case) it asks the user whether it should start the service. That’s good! Tell the user that some needed service is missing and offer the means to start it. Give the user a choice instead of hiding processes. The user might have lost three seconds but he gained knowledge about a service that will consume a considerable amount of RAM and CPU-power. It’s not some small plasma or kded service!

Now if the user quits kmail akonadi will not quit automatically. Why not? Because it does not know whether it is still needed by other apps. As a result it consumes bandwith, RAM and CPU although it is not needed anymore. That’s bad! The fact that akonadi is not stopped when not needed anymore is another aspect where akonadi differs from some small plasma service that is started automatically (hidden) if the user adds the related widget. It is different because the latter also stops the service as automatically and hidden as it started it when the user removes it – thus there is no need to bother the user.

So why not simply ask the user in case of akonadi? Kmail asked the user whether to start the service, so why does it not ask whether it should stop it? If the user would want akonadi to run all the time he would autostart it with the session, would he not? And if kmail can ask the user to start akonadi why can those applications that still need it not do the same? What is wasting more resources and annoying a) to have akonadi in memory just in case there is some other app using it or b) let the user take a decision which takes two seconds? Worst case scenario would be that the application that needs akonadi tells the user to start it, as kmail did in the first place. Remember – if the user would want akonadi to run all the time he could start it as part of the session or click once on some “never quit akonadi” button.

Another approach would be to let kmail ask akonadi whether there are other applications using it. Either applications using it have to register with akonadi or respond to a “who needs me?” query by akonadi. That way the user could get a list of applications using akonadi and decide whether he wants to keep it in memory or not. He knows, the application just guesses or assumes. And it should only be the user that decides when it comes to a “do always”-kind of question. He might as well decide to “always quit akonadi when kmail quits” or “never quit akonadi when kmail quits” or “akonadi should quit as soon as there is no app answering to a ‘who needs me’ query”.

What makes it worse not to ask and just assume that staying in memory is ok is that there is no easy way to stop akonadi. There is no systray icon indicating its status and allowing interaction. There is no start/stop in systemsettings’ PIM module (as there is for e.g. nepomuk). There is no entry in systemsettings’ start/stop module. So even if the user knows about these systemsettings modules he cannot stop akonadi.

IMHO stopping something should be as easy and automatic as starting it. If that’s not the case it is an usability fail. I know that there is akonadictl but that is out of reach for most users and just underlines that stopping is not on the same level of ease as starting. The latter implies that once started the app thinks it is better not to be stopped again.

Lancelot

An even worse example is Lancelot. Adding a plasma widget starts an application without even asking or at least notifying the user. This would be kind of ok, if that application would be stopped as easy and automatically as it was started, as plasmoids can do, yet it is not!

Removing the widget lets lancelot stay in memory just in case there are other apps using it. According to the developer asking the user is out of question because it would involve user-interaction. So in the end you add a widget and remove it and yet have some useless app left wasting megabytes of memory, CPU-time and querying e.g. akonadi. There is no way to stop it via systemsettings. Yet the latter would not help anyway since the user does not even know that some memory/CPU wasting app was started without his knowledge int he first place.

Again wasting resources just in case there might be some app that needs the service is seen as the best way instead of simply asking the user. In times of suspending instead of rebooting and mobile devices this means that lancelot will happily waste your memory and CPU-time for ages although it is not needed at all. Simply because a three second user-interaction is considered bad by the developer. What makes people think that wasting their resources is less annoying to them than interacting with them once in a while?

And of course you are right to claim that nobody forces people to use e.g. Lancelot. Absolutely true! But that is just another reason to not pest those users with your application until they restart their session. They think they stopped everything as explicitly by removing the widget as they allegedly started it explicitly by adding the widget. Did we not all make fun of MS Windows because you had to restart it for all kinds of changes and when removing software?

So IMHO: If an application is not smart enough to know what the right thing to do is and whether it might waste RAM and CPU just for the sake of not interacting with the user – not even once: please ask the only expert regarding what the user wants – the user. Don’t try to be smarter than the user if the alternative is as easy as a single user-interaction. At an absolute minimum provide the user with the graphical means to stop whatever you thought necessary to start automatically but not stop automatically, e.g. via systemsettings as nepomuk does.

UPDATE: Since I seem to not have got that point across very well: I would also like to avoid questioning the user but that needs the service to behave as it was mentioned in some comments by others. As long as it does not do that, I prefer to decide what should be done with services that are not needed by any clients.

UPDATE 2: Since some people could not help themselves but simply claim that my figures on akonadi/kdepim’s memory consumption were wrong and would not even hint towards real memory consumption getting out of bounds, I’d like to point out that using /proc/PID/smaps one can measure the private dirty memory consumption of a process. In KDE’s system monitor you can reight-click a process and pick “detailed memory information” to get that info. So bottom line is, unfortunately my figures were real, are reproduceable on my system and reported to the devs. So for people like Nathan – please don’t get too defensive and aggressive next time – just in case you are wrong. And please do not start claiming that even smaps and private dirty memory consumption is not “real”.