Some guess of protocol specifications and details

Capabilities_to_add

@@ -0,0 +1 @@
+setcap = cap_wake_alarm=pe <executable>

doc/Random_notes

@@ -0,0 +1,47 @@
+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
+