Re: PIPI (Parsed Input Process Initiator) -- another silly proposal?
On Wed, Jul 26, 2000 at 05:11:24PM +0300, Pavel M. Penev wrote:
>
>
> On Wed, 26 Jul 2000, Colin Watson wrote:
>
> > I don't see what user interfaces have to do with standard input and
> > streams, particularly (at least not any user interface that differs
> > across platforms), nor do I really see how this helps portability. I
> > think you can pipe streams across network connections easily enough with
> > current mechanisms, and since said mechanisms are composed from the
> > normal shell-based ways of initiating network connections I think
> > they're much easier to understand than yet another syntax would be.
>
> Sorry, I think I have not been clear enough. I will use now
> examples. Imagine a simple stereo audio player. It needs to have two
> channels of audio data at the same time (synchronised). Now the
> application requests the two streams (named, for instance, "chan_l" and
> "chan_r") from its shell. Then the shell could pipe "chan_l" from filter
> 1, and "chan_r" from filter 2. Imagine filter 1 reads from file, and
> filter two generates the output. Now imagine you want to port this
> application to another platform. What do you do? Recomplie it for the new
> hardware and use the same source. The application would just run under a
> shell for the new platform. Moreover, if you port filter 1 to the new
> platform, you get the same file format you used on the first platform. In
> addition you could specify a new filter for the new platform (e.g. because
> another file format is used under it). And would do this all with the same
> source of the core application.
Hmm. You mean something like this:
[audio player expects left audio on FD 3 and right audio on FD 4]
bash% audio-player 3< left.wav 4< right.wav
[the extension to pipes instead of files is left to the reader, who
will want to consult the manual pages for his shell for the advanced
redirection commands]
I have yet to be convinced that the proposed package offers anything
more than standard unix facilities (even if some, like the above, are
underused).
Jules
Reply to: