The daemon needs to know (for each task):
- Some identifier
- Times of start and repetition			AND be able to calculate the upcoming repetition?
- Formula to check						ALSO for each variable a list of task to be recalculated.
										FOR task with implicit variables: that that task should be recalculated every time
- Command to be run
- Which timer shall be used				ERROR if daemon needs CAP_WAKE_ALARM but doesn't have it.
- User note?

Socket comunication scheme:				Q: shouldn't it be a fifo instead?
- One line: \n terminates a request
	- Request from client ending with \n, then a line from the daemon with status.
- Status lines: keyword, optionally with details after a space
	* 'OK' = the request has been processed as expected
		- 'OK but' + obsolete, dangerous, ... = still a success, but shouldn't be used that way.
			- Clients are still free to ignore the details.
		- also return task ID when creating a task
	* 'SYSERR'+␣+errno line = Some of the syscalls failed
	* 'SYSBUSY' = Syscall error, possibly fixable by trying it again (EBUSY, EAGAIN, ...)
		- This shall be done by the client, so that the daemon can process other requests
	* 'PARSEERR' (maybe what failed) = The daemon was unable to parse the request line
		- also nonexistent variable and all errors with the request
	* 'ERR' = Other kind of error. This should not end up being overused.
	* 'NYI' = The request type is not recognised or implemented.
	* 'DATA'+␣+data = for data exporting from the daemon to the client (task list).
		- Implicates 'OK', if anything fails, we fail
		- Maybe break the convention of single line from each? Then each line start with DATA, and last with 'DATAEND'?
			- DATAEND has the advantage of us knowing the data is all, even for empty data.
		- or encode it in a single long line??
I should define status codes and classes, so that old clients can parse new errors. Maybe.
- Requests: Type, space, parameters
	* 'TASK' = adds a new task
	* 'VAR' = adds/sets a variable
	* 'TASKDEL' = delete a task
		- there is no such thing as disabled task
	* 'LIST' (selector?)
	- Support for task changes? Not needed, can delete and make new task, but may be nice
	- Metainformation like 'VERSION'?

Semantics detail
- Variables are always numbers
	- Variables not defined are either a fail, or zero AND I AM THE ONE WHO SHOULD DECIDE WHICH IS THE CORRECT BEHAVIOR
	- Variable names consist only of uppercase letters and underscores
		- And maybe they have limited length?
		- lowercase names are reserved for function names and maybe implicit variables
			- Should it be guaranteed uppercase names are all free for user to use? I think so