Re: Question about linemode implementation...

[Steve Parker <[e-mail]>]

- > To me, it seems clear that the server would refuse to negotiate those
- > options if they were in conflict with the present state of the "pty"
- > set by the application.  For example, if the application has set the
- > pty into "raw" mode, negotiating remote edit should probably be refused.
- > (And I think I can make similar arguments about flow, trapsig and echo.)
- 
- On a typical UNIX based system, you can do things like "stty -echo".
- This would change the state of the pty, which notifies the telnetd
- of the state change, and it then sends a MODE command to the client
- to let it know of the change.

Sure.

- The telnet client interface allows
- the opposite to happen.  The client sends the MODE command to the
- server, it takes the new mode and sends it to the pty, which then
- becomes apparent to any application that looks at the pty state.

So when should it look at its pty state?  Before now there hasn't been
anything turning on and shutting off bits like "ECHO" and "ICANON".
The application isn't _notified_ when this stuff gets changed.  And
applications shouldn't have to be changed to work with telnet.

If the application allows echo, then it seems perfectly fine if telnet
negotiates echo back and forth between local and remote.  It doesn't
seem fine to me if the client can re-arrange virtual terminal behavior
my application has specified.  It also doesn't seem right to me that
the application should see the "echo bit" off, just because echoing
is being done by the telnet client.

At least in the UNIX world, a process which continuously holds a
controlling terminal does not need to keep querying the terminal
modes:  it is assured the system isn't going to change it.

I guess this means I'm unconvinced?  :)

Cheers,

	~sparker