TODO: add planned features for next release.
authorDavin McCall <davmac@davmac.org>
Tue, 12 Jun 2018 17:20:25 +0000 (18:20 +0100)
committerDavin McCall <davmac@davmac.org>
Tue, 12 Jun 2018 17:20:25 +0000 (18:20 +0100)
TODO

diff --git a/TODO b/TODO
index 002f4a8e6547cc6ad7e544759759d111bce775cf..a3db9b01c6fa83b4f72577062320ee821e6f8dde 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,6 +1,14 @@
 For version 0.3.0:
 ------------------
-* (Not yet decided).
+* Skippable services: if they terminate via ^C, treat as a successful startup. Allows
+  skipping filesystem checks.
+* Provide better status information:
+  - whether a service failed to start (as opposed to just being STOPPED)
+    - directly, and how (error code? died to signal? timed out?) or
+    - due to a dependency.
+  - whether a service has acquired, or is waiting to acquire, the console
+  - whether service was skipped (via ^C/SIGINT) instead of started normally.
+* Option to send signals to service process leader only (not to process group).
   
 For version 1.0:
 ----------------
@@ -14,12 +22,15 @@ For version 1.0:
 * A (perhaps limited) way(s) to modify a service description after it is loaded -
   eg add/remove dependencies, change properties.
 * Think about detecting runs-on-console dependency conflicts (i.e. if A runs-on-console and
-  B depends on A and runs-on-consle then B can never start).
+  B depends on A and runs-on-consle then B can never start)?
+  - Complicated if service descriptions can be altered after loading. Perhaps not necessary
+    if better status information can be provided.
 * Documentation must be complete (see section below).
 * Package-manager-friendly way to enable/disable services.
   Perhaps a service can specify a dependency file (with dependency type) where
   the file contains a list of service names, or if it is a directory, each
   filename within corresponds to a service that is a dependency.
+* Proper support for socket activation?
 * Be able to boot and shutdown Linux and FreeBSD.
 
 For later:
@@ -43,6 +54,13 @@ For later:
   But perhaps this really the responsibility of another daemon.
 * Allow running services with different resource limits, chroot, cgroups,
   namespaces (pid/fs/uid), etc
+* Support chaining service output to another process (logger) input; if the
+  service dies the file descriptor of its stdout isn't closed and is reassigned
+  when the service is restarted, so that minimal output is lost.
+  - even more, it would be nice if a single logger process could be responsible
+    for receiving output from multiple services. This would require some kind of
+    protocol for passing new output descriptors to the logger (for when a
+    service starts).
 
 Even later / Maybe never:
 -------------------------