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:
----------------
* 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:
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:
-------------------------