NRJ looks cool (Based on NetRexx it *had* to be cool), and as I recall
surprisingly complete. But I did not get very far in understanding it. I
also have an outstanding concern: can it drive stages simultaneously and
natively outside of the JVM?
As a community, we've always been critical of Unix shell pipes. Gotta
get past that byte-oriented design. We observe smugly that "they" wind
up implementing records: packets, messages, datagrams, chunks, blocks,
whatever. The Unix guys always had the tools to get it right. They just
needed to follow the Piper. Ah well ... history passes and Waters throws
himself under bridges.
I confirmed that using a _pair of POSIX pipes in opposing directions_
gives us _bounded records and flow control_. Using standard POSIX pipes,
the implementation runs on lots of platforms and gets concurrent native
simultaneous execution of all stages. *Control* flows upstream, *data*
downstream. Consumer says, "tell me what you've got" on the upstream
control line, then reads the data line (blocking read). The producer
says, "this is what I've got" on the downstream data line, in particular
how many bytes, but doesn't send the record just yet. Consumer can then
decide if it wants this record, if it has a big enough buffer, if it
maybe wants to do an 'ADDPIPE' before continuing.
The record is bounded. If the consumer wants to peek or read the record,
he tells the producer (on the upstream control line), "give me what
you've got". Producer then sends the data on the downstream data line.
It's a record, just a bunch of bytes, unmodified, unencoded, raw.
Consumer slurps all bytes, exactly that many bytes, and nuthin but those
bytes. Consumer function then either returns immediately (for a
'peekto') or signals "got it!" upstream on control line to the producer
(for a 'readto') and then returns.
A 'CONSOLE' stage written in C (just the code for end of the pipeline,
consumer mode only) might look like ...
while (1) {
rc = peekto(INPUT,buffer,sizeof(buffer));
if (rc < 0) break;
buffer[rc] = 0x00;
printf("%s\n",buffer);
readto(INPUT,NULL,0);
}
Lots of presumptions, like the stream is textual content, but you get
the idea. Return code is number of bytes or is negative if there was an
error. This example doesn't handle 'CONSOLE' at the start or in the
middle, yadda, yadda. peekto() and readto() of course talk to the
producer using the upstream control and downstream data file
descriptors. output() in the producer does the opposite.
Started a project years ago. Never had time to really get it going.
Eventually put most of that onto GitHub, and tinker with it every few
months.
Wanna play?
-- R; <><
On 3/22/19 12:10 PM, Ray Mansell wrote:
> Coincidence... I have been looking for the same thing over the past few
> days. I have a very old version of Pipes for Windows somewhere, but that
> was from long ago, and was only a partial implementation. What I did
> find, however, is that something called NJPipes is now included as part
> of NetREXX, and it appears to be a far more comprehensive implementation
> of Pipes.
>
> I have yet to install it and start experimenting, but if you're
> interested, start here: http://www.netrexx.org/downloads.nsp
>
> After unzipping the download, explore the documentation to get an idea
> of what is available. That's just what I'm about to do myself.
>
> Good luck,
> Ray
>
> On 3/22/2019 06:50, [email protected] wrote:
>> The only hint I found about PC-Pipe's existence is a 10 years old
>> append announcing an update of PC-Pipes, alas today the link is dead.
>>
>> Questions:
>> i) is there a result from the efforts to migrate Pipelines to the
>> PC world, comparable to the original?
>> ii) where may I find it?
>>
>> Ciao.....Mike
>> --
>> www.Ok.de - die kostenlose E-Mail Adresse
