[TransWarp] input-driven application

[alexander smishlajev]

Phillip J. Eby wrote:
> 
>>   the whole assembly may look like this:
>>
>>   DA1 => ILC => T => OLC => DA2
>>       <=                 <=

>> in this scheme, T is classic filter by all means, but ILC and OLC are 
>> not.  ILC has it's stdin and stdout on the left side and additional 
>> file-like object (pipe input) on the right side.  OLC has it's stdin 
>> and stdout on the right side and additional file-like object (pipe 
>> output) on the left side.
>>
>> i am not sure yet how to describe the third stream for link control 
>> components.  if you have something to suggest, i would highly 
>> appreciate it.
> 
> Well, as long as you have a pipe mechanism, there is nothing stopping 
> you from defining attributes such as say 'linkout' and 'linkin' on the 
> appropriate pieces, and then grafting them with a pipe as you do all the 
> others.  There is nothing magical about the 'stdin', 'stdout', etc. 
> bindings on PEAK command objects.
> 
> But perhaps I'm misunderstanding your question.

perhaps.  there is no problem with complete application assembling the 
whole chain: as far as i understand, the main component may just pass 
file-like objects as a keyword arguments of the AbstractCommand 
constructor for ILC and OLC objects.

but since those ILC and OLC objects are theoretically runnable by 
themselves from the command line, i'd like to have some machinery 
allowing to run them via 'peak' bootstrapper, with 'linkin' and 
'linkout' given in commandline options as either disk files or (in 
shells more advanced than command.com) file descriptor numbers.

... but please don't care.  i am sure there is a not-too-complicated 
solution for this.  i just need to think about it a little more.

thank you,
alex.