> > The idea of Parameters are "borrowed" from the UNIX command line, so > > that Parameters are supposed to be like command line options. So > > inputs and outputs describe the information that passes in and out of > > a Node, and the parameters can affect how the Node processes the > > inputs to produce the outputs. > > This is because Piper draws very strongly from the UNIX paradigm, and it > should continue to do so in any new features. Not very helpful, but it's my > $0.02 on the subject :-) A guy at work with whom I was discussing the idea of a graphical shell used to call that the standard control stream (stdctrl for short). That offers a nice symetry: stdin/stdout, stdctrl/stderr. I've been looking for a killer application (i.e. really good use case) of the dynamic standard control since then, but haven't found it yet (it quickly gets quite complex if you allow it to change during the processing of the stream). It shallows somewhere in Narval's design, but you have to know it's there to spot it. My opinion is that piper should use it for static parameters and keep it in long enough for the good idea to show up by itself. If you're interested in software composition in general, it may worth it to have a look at CHAIMS (http://www-db.stanford.edu/CHAIMS/) and it's concept of "Megaprogramming" (funny name isn't it :-) -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)