plumb (v3) design decisions

priorities

In order of importance:

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: Note: original implementation was with multiple fds, up to r600.