4 ms·

Context is stdin and stdio. "It kind of breaks the Unix/Linux piping paradigm using these streams for bidirectional communication." Uhm ... no? They were mean

Context is stdin and stdio. "It kind of breaks the Unix/Linux piping paradigm using these streams for bidirectional communication." Uhm ... no? They were meant for that. But the rest of the critique is well founded. "Streamable HTTP" is quite an amateurish move.

OJFord 1y ago
I think 'bidirectional' is unclear there, they really mean a back and forth dialogue, interactive bidirectional communication. Which, yeah, a socket (as they said) seems a better choice.
- moralestapia 1y ago
  I think stdin and stdio are meant to always be piped forward, and a program further down the pipe cannot modify a tool back in the pipeline, maybe that's what he's trying to convey with "bidirectional"?
  - OJFord 1y ago
    I don't think so, because it's a description of a system which does work. But it's more like an HTTP API, writing or requesting some data, getting a response, doing something else with that, etc. - whereas typically with stdin/stdout you're doing something more like `generate-data | transform | transform2 | store`, manipulating an initial input, not decision-making and providing more input based on the output of early input. Not to say you can't, but it does seem a bit weird to me too. (To be fair I suppose a shell is an obvious counter-example. Or anything that launches an interactive prompt or interpreter.)
kelnos 1y ago
> They were meant for that. No they weren't. If we look at it from the perspective of pipelines (and not interactive programs that take input directly from the user and display output on the screen), stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you. That's not bidirectional, that's a unidirectional flow.
- moralestapia 1y ago
  You are wrong. STDIN means Standard INPUT. STDOUT means Standard OUTPUT. There is no design/hardware/software limitation to reading and writing to them at the same time. That's your bidirectional channel with that one process. >stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you Yes, and you took that from my comment here: https://news.ycombinator.com/item?id=43947777 https://news.ycombinator.com/item?id=43947777 Did you just wanted to ratify my argument, or is there something else you want to add?

OJFord 1y ago

I think 'bidirectional' is unclear there, they really mean a back and forth dialogue, interactive bidirectional communication. Which, yeah, a socket (as they said) seems a better choice.

moralestapia 1y ago
I think stdin and stdio are meant to always be piped forward, and a program further down the pipe cannot modify a tool back in the pipeline, maybe that's what he's trying to convey with "bidirectional"?
- OJFord 1y ago
  I don't think so, because it's a description of a system which does work. But it's more like an HTTP API, writing or requesting some data, getting a response, doing something else with that, etc. - whereas typically with stdin/stdout you're doing something more like `generate-data | transform | transform2 | store`, manipulating an initial input, not decision-making and providing more input based on the output of early input. Not to say you can't, but it does seem a bit weird to me too. (To be fair I suppose a shell is an obvious counter-example. Or anything that launches an interactive prompt or interpreter.)

kelnos 1y ago

> They were meant for that. No they weren't. If we look at it from the perspective of pipelines (and not interactive programs that take input directly from the user and display output on the screen), stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you. That's not bidirectional, that's a unidirectional flow.

moralestapia 1y ago
You are wrong. STDIN means Standard INPUT. STDOUT means Standard OUTPUT. There is no design/hardware/software limitation to reading and writing to them at the same time. That's your bidirectional channel with that one process. >stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you Yes, and you took that from my comment here: https://news.ycombinator.com/item?id=43947777 https://news.ycombinator.com/item?id=43947777 Did you just wanted to ratify my argument, or is there something else you want to add?