You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
48 lines
2.6 KiB
Plaintext
48 lines
2.6 KiB
Plaintext
7 years ago
|
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
|
||
|
|
|