Re: [Queue-developers] Cross-platform termios handling...

[W. G. K. <wer...@ya...>]

One of the early drafts of the internet protocol actually included the telnet 
WILL/WONT mechanism for negotiating various things.

On reading the RFCs for several telnets, I discovered that it was very 
complicated, however. One of the later RFCs complains that the original RFC for 
telnet describes a protocol that doesn't work. A big problem with this option 
negotiation is ensuring that the negotiation terminates.

I felt it would be difficult to implement this properly. Moreover, it was to far 
away from the way Queue currently did things, so I removed this from the 
protocol. The final draft of the submitted draft protocol is very close to the 
way Queue actually does things, and you might say that 1.20.1 is a draft 
protocol-compliant implementation.

Of course, the draft protocol is just a draft, and if there's strong feeling in 
favor of this mechanism (e.g., someone supplies code that actually implements a 
telnet-style WILL-WONT mechanism in Queue) then we can go along with this.

However, I don't think we need option negotiation. We just need to pass a 
superset of all supported options, and then let the other side support whatever 
it can support or refuse to provide service.

The rlogin protocol is quite different from telnet. It doesn't use option 
negotiation AFAIK. It passes the lowest common denominator of terminal 
information, i.e., a subset of termios, to the other side. This works, and 
rlogin has been implemented on many non-UNIX platforms as well, so it can be 
done transparantly.

We don't have to follow this approach either. We can pass the Linux termios 
structure (a superset of termios on many systems) and then let each system pick 
and choose want it wants to support.

For simplicity, however, we could write a translator function that translates 
Linux termios to the simplified rlogin structure (portable) and then use code 
from rlogin to translate the simplified structure to machine termios on 
non-Linux systems. This might save us some porting effort.

In the end, though, we should do this in simpliest possible way, and if people 
have ideas they should speak up (or provide code. :) )


Quoting Andrew Phillips <at...@pe...>:

> Hi,
> 
> > Based on this description, it's unlikely that Expect sends terminal
> information 
> > over the network. (On the other hand, rlogin and telnet do send terminal 
> > information over the network, so perhaps we should look at the code base for 
> > these two programs. Ultimately, however, they will have to translate
> information 
> > to termios structures as well -- there's no way to completely get around
> this. 
>     
>     The telnet RFC plus the EDIT/Linemode extension RFC contains a pretty
>     complete description of the way this is done.
>     briefly, telnet defines an 'escape' character, plus a whole of modifiers,
>     and during the course of a telnet connection conversations like
>     
>     (telnet)  DO ECHO
>     (telnetd) WILL ECHO
>     turns remote echo on.
>     (telnet)  DONT ECHO
>     (telnetd) WONT ECHO
>     turns remote echo off.
>     
>     (These actually occur in binary, but these are the mnemonics used in 
>      the RFC.)
>     
>     Likewise for edit. The client and server negotiate capabilities, 
>     and settle on a combination of line editing in the client and 
>     on the remote host. They dont actually transfer termios structures
>     or similar across the network, as it was intended as a platform 
>     independent virtual terminal, with servers running on all sorts 
>     of systems ranging from VAX/VMS, MVS, and UNIX, only one of which
>     understood termios at that time. 
>     
>     Another extension allows the transfer of a users unix environment
>     including the TERM environment variable across the connection. 
>     
>         Hope this helps.
> 	   Andy
> 
> -- 
> Dr Andy Phillips                                 at...@pe... 
> Pergamentum Solutions                              at...@co...
> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> _______________________________________________
> Queue-developers mailing list
> Que...@li...
> http://lists.sourceforge.net/mailman/listinfo/queue-developers
>