[FoRK] taxonomy of composition and coordination (thinking out loud...)

Jeff Bone 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  
stronger?

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  
used?
(6)  if not name-based coupling, what?  (channels;  generative  
dispatch;  ...?)
(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...


jb



More information about the FoRK mailing list