Re: tn3270, mset and map3270

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Not so much Unix-derived; other OSes also tend to expect serial
>> lines to carry characters rather than keystrokes [...]
> Well, yes.  But only Unix has this enshrined in the tty subsystem.

VMS did, and presumably does, too.  Anything which has "special
characters" of any sort (input line editing, signal-or-equivalent
generation, etc) must have something of the sort.

> Elsewhere (e.g. in DOS, AmigaOS, etc.) a serial port is something
> that sends octets, and you can run anything you want over it without
> getting in (much) trouble.  In Unix owing to some poor early design
> decisions you need a special-case kernel hack to support each new
> such application.

You do?  Ever hear of raw mode?  -icanon -ocanon -isig, mostly (there
may be a few other bits that have to be turned off) in stty(1)-speak;
it's not hard to turn a serial line into a raw octet channel.

> We already have those hacks in place for SLIP and PPP and a few other
> things, but otherwise it's a pretty painful mess.

The only reason SLIP and PPP need their own line disciplines is that
they are in the kernel.  If they were implemented entirely in user
land, they would need nothing more than ordinary raw mode.

> Well, you'd need to make your examples/argument quite a bit stronger
> to persuade me that what you want can't or shouldn't be done some
> other way.

Honestly, I don't much care what you think can or should be done
differently when it comes to designing the applications I run.  I am
not going to rewrite this application, nor any of the others I may turn
out to have, to accommodate your ideals; if you break NetBSD
sufficiently that it won't support such code, you will lose NetBSD a
user.  (Small loss, I suppose, since I clearly shouldn't be using it
the way I am.)

> Especially when I have my system architect hat on and I'm thinking
> about other concerns as well, like vt bombs.

There is nothing that can be done about those unless you completely
break the use of serial lines to carry arbitrary octet sequences, which
will also exclude many non-user-interaction uses of serial lines.  I
suppose that doesn't matter, since they too shouldn't be using the
system the way they are?

> If you say so, but I must say that it sounds like you have cases
> where $20 of hardware (probably faster terminals / better cables)
> would solve the problem better.

For your values of "better", perhaps.

>>>> [...] ship a copy of libtermcap [...] with my application.
>>> [...] accomplish no more than redboxing on a tcpip network. :-)
>> [...], I don't see the similarity.
> Emitting in-band terminal control signals to a screen device that
> doesn't support in-band signalling is fairly useless.

I don't quite get it.  I raelly see only two interpretations.

(1) You propose to drop support for conventional terminals attached to
serial lines (which perforce use in-band control) and redesign all
terminal emulator equivalents to speak to your curses[%] implementation
via some mechanism other than the one used for text content, thus doing
away with in-band escape sequences[$] entirely.

(2) You propose to somehow make your curses[%] implementation
sufficiently special that it can emit escape sequences[$] to terminals
or emulators, but applications not using it will produce some other
effect if they try.

[%] "curses" is shorthand for the list of blessed APIs (curses plus
line editing plus whatever else).

[$] "escape sequences" is shorthand for all in-band terminal control,
whatever you decide has to be prevented.

Neither of these strikes me as at all plausible; each involves a fairly
radical redesign and would break a hell of a lot of third-party code.
But I can't see anything else that would cause an application doing its
own terminal-or-emulator control via its own termcap equivalent to be
talking to "a screen device that doesn't support in-band signalling".

You wrote, upthread, that the motivation behind this was to "find and
kill" all code that used termcap or terminfo rather than whatever
interfaces you propose to bless instead.  That option is not available.
The most you can do is prevent them from being shipped with NetBSD, and
render them difficult to run on NetBSD; you cannot eliminate them, and
you cannot render them impossible to run on NetBSD without removing
users' ability to hack on NetBSD.

Perhaps that's the direction you want to go.  Maybe it's even the
direction Core wants to go.  I think you'll find that what you end up
with isn't very Unixy, though, and won't be very popular with NetBSD's
existing user base - it certainly would drive me for one away.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B