Re: closing a channel

[nisse%lysator.liu.se@localhost (Niels Möller)]

Wei Dai <weidai%eskimo.com@localhost> writes:

> What do you think about this proposal: link CHANNEL_EOF to all of
> CHANNEL_DATA, CHANNEL_EXTENDED_DATA, and CHANNEL_REQUEST, and create two
> new channel message types: CHANNEL_DATA_END, linked only to CHANNEL_DATA,
> and CHANNEL_EXTENDED_DATA_END, linked only to CHANNEL_EXTENDED_DATA.
> CHANNEL_EXTENDED_DATA_END would look like this:

I don't like it. It's too much extra complexity for a small very gain.
It's the kind of improvement that identifies a design by a committee...

For most channels, sending EOF when you don't want to send any kind of
data, and CLOSE when you want the channel to go away, are exactly the
two messages you need. Then enters the EXTENDED_DATA hack, which so
far is used *exclusivelt* for session channels, and which has the
minor bug that it doesn't quite separate the stdout and stderr flow
(as what should have been two independent flows share both EOF
notifications and the flow-control related messages).

The situation could be improved, but then the right way is *not* to
introduce more variants of the EOF message to clean up after the
EXTENDED_DATA hack, but to introduce a new CHANNEL_OPEN or
CHANNEL_REQUEST messages that attaches a separate stderr channel to a
session.

And the bottom line is that I think EXTENDED_DATA, while not perfect,
is still pretty good, good enough that we shouldn't bend the rest of
the protocol to "fix" it. And I encourage anybody that is annoyed by
the limitations of EXTANDED_DATA to experiment with things like

  CHANNEL_OPEN "stderr-for-session" session

without changing our now almost standard core protocols.

Regards,
/Niels