Re: tn3270, mset and map3270

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

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

>> (1) [...]

>> (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.
> Nope... it is a sign of how deeply ingrained the design mistake is
> that you don't see that any alternative approach is possible.

I don't think so.  What you describe sounds like (2) to me (which is
why I re-quoted it in full).  See below.

> In Unix, all serial ports are ttys and all ttys are serial ports.
> Both directions of this implication are wrong.

To the extent that the former is true, I agree with the latter.

But the former isn't quite true; for example, NetBSD/sparc and
NetBSD/sun3 have serial ports to which keyboards and mice, not tty
devices, attach.  Here, for instance, is how the serial ports on the
machine I'm typing this on are reported at boot time.  (kmmux is a hack
of my own, a reverse multiplexer; in stock NetBSD I think this would be
kbd0 at zs1 channel 0 and ms0 at zs1 channel 1.)

zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6
zstty0 at zs0 channel 0
zstty1 at zs0 channel 1
zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6
kmmux0 at zs1 channel 0 (console, 1200 baud)
kbd0 at kmmux0 (console)
kbd1 at kmmux0
kbd2 at kmmux0
kmmux1 at zs1 channel 1 (1200 baud)
ms0 at kmmux1
ms1 at kmmux1
ms2 at kmmux1

> The abstract interface for a screen-mode application should be a
> screen.  When there's legacy hardware involved, converting the screen
> representation into updates composed of terminal control sequences
> should be done by system software, not applications.

Arguably.  I'm not entirely convinced it's possible for one screen
updater to fit all needs.  It's probably worth trying.

This sounds like my (2), with my "your curses implementation" being
what you called "system software" in the above paragraph.

It's an interesting approach.  I'm not sure it's a good idea to promote
"full-screen screen" to the status of being a full-fledged OS object,
but I'm definitely not sure it's a bad idea, either.  It'd be an
interesting experiment, at the very least.

> The downside of this approach is that if you want to be able to run
> screen-mode programs from a serial console (as opposed to just log in
> on serial-connected terminals) the realities of the system structure
> require that curses be moved into the kernel as a device driver.

I'm not so sure.  I don't see that as being necessary; it could be done
with the help of a program which speaks "serial terminal" out one side
and "full-screen interface" (whatever that turns out to be) out the
other.

Fitting this into the Unix model of "everything is an octet stream"
could be difficult, but I suspect that would be the hardest (and
probably most interesting) part of it.  The problem doesn't really fit
the octet-stream model very well.

> This is not entirely desirable for assorted reasons. (Although it is
> perfectly *appropriate*, as curses is and always has been abstraction
> code for controlling hardware devices.)

Err...I'm not sure that means it's appropriate to put it into the
kernel.  Not all abstraction layers belong in the kernel.

>> 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.
> Yes, it is.

I don't think so.  The software is out there, and you are not in a
position to force the people distributing it to stop.  Nor, even if
your guesses about uptake rates are right, are you likely to persuade
them to, given how long installed bases survive.

> Realistically, most non-legacy screen-mode applications use curses;
> most people who have a legacy screen-mode program written using raw
> termcap would be happy to take modernization patches; and I'm pretty
> sure a well-designed line-mode library would get fairly rapid uptake.

"Most"..."most"..."pretty sure".  That's a long way from "...find and
kill all...".

/~\ 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