plumb (v3) design decisions
priorities
In order of importance:
- portability using libporty; make sure the same script does the same thing on all supported platforms
- clean, orthogonal design
- minimize redundancy of features
- core should do all the complex operations on processes, pipes, fds with minimal amount of side effects; side effects (such as splitting/merging data streams, buffering, record splitting and merging, etc.) shall be implemented in VPs
- because of using VPs instead of core side effects, increased amount of typing is required while using plumb; offer libraries to make daily use of plumb convenient
- strong documentation in form of man pages (user doc) and html (user and developer doc)
- make it easy to develope VPs with good understanding of plumb concepts and minimal understanding of plumb core sources
- offer large variety of VPs but avoid redundancy; if something can be achieved combining a set of existing VPs, do not implement a new VP
- native support for binary streams, even for mixing binary and text streams in both directions
core
#TODO:
blocking/flow control
- it is possible to implement a virtual process that can still accept input
while its source is blocked, and grow an internal buffer up to a configured
limit before sending back block on its source.
- an event could be emitted when a real process gets blocked, then
its up to the user to run a separate process reading events and
deciding what to do (kill/restart/whatever); may generate excess amount of
events!
VPs
networking
The _only_ reason for built-in networking is that it comes for free
with libporty; any external solution would be more expensive and might be
less portable.
[cmd]
Instead of one central cmd=[cmd] that handles all (i.e. with env), the user
shall create multiple [cmd]s. Each [cmd] has its own single parser. Reasons
for this decision over a central one with multiple parsers:
- [cmd] can become interactive and deliver answers on stdout that
can be piped back in the process generating the script; with a single
[cmd] process it would require some extra infrastructure to figure
which input fd is correspoinding to which output fd
- the transaction context (compilation input file name) is more
meaningful: it's the name of the [cmd] process instead of the number of
the fd
- simpler design, probably less surprising for the user
- less code, less user documentation
Note: original implementation was with multiple fds, up to r600.