[FoRK] taxonomy of composition and coordination (thinking out loud...)
jbone at place.org
Mon Dec 14 05:24:41 PST 2009
Dr. Ernie asks:
> Where would you put tools like ssh, Capistrano, and other flavors of
> remote shell / configuration?
They would likely fit somewhere between the first and second entries
in that taxonomy. (I.e., showing its incompleteness.) Pipes in
general, when extended over the network, show the weakness of making
networks transparent. (Try pumping a lot of data over an ssh
connection at close to line speed, for any fast line.) They're
synchronous in that they block, but not really...
Really, the difficulty here is in really rounding out e.g. Rohit's
work on similar issues to capture all the critical dimensions of
composition and coordination. Such a taxonomic set of features would
be useful (academically, and perhaps practically) in its own right,
but my goal is really more along the lines of understanding how to
make composition as easy as e.g. pipes but more general and flexible,
for use in my own pet project and for my own understanding.
I.e., what *is* it that makes reuse in e.g. the shell so easy, and so
hard everywhere else, and how can we generalize that and make it even
It seems that there are several potential dimensions of composition:
(1) is there some kind of reified "connection" or channel between
communicating components? (Vs. "just" messaging.)
(2) do all components support the same set of interfaces?
(3) is communication synchronous (blocking, implying return value) or
async (non-blocking, no rv per se)
(4) is there flow control, and how is it handled?
(5) do components know each other by name? What kinds of names are
(6) if not name-based coupling, what? (channels; generative
(7) what's the relationship between the transport-level metaphors and
the higher-level ones?
(8) sharing of state, mutability of data, etc.
etc. (Again, not presenting this as a complete set, or consistent.
Just thinking out loud...)
BTW, thanks to Sean for reminding me about QNX. Thinking about
explicit element-wise node addressing has generated some interesting
questions / ideas over the last 24 hours...
In particular, one of the things I've wrestled with for a while now is
formalizing the notion of a UNIX-like process. What is it, exactly?
The sort of rough definition I've been working from is that it's a
partial function from streams, args, etc. (i.e. tuple of (stdio, fds,
env, args)) to same (sans args, plus return value). The curried
function is reified by providing e.g. args and env, then yields a
function from streams to streams + argv. That's not really
satisfactory. In particular return values are a problem. I'm sure
it's in the more general literature, but (aha moment!) pure functions
with return values can be modeled in the pi-calculus with uniqueness
types as processes that have a one-shot return value channel.
More thinking out loud...
More information about the FoRK