Re: tn3270, mset and map3270

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Mar 11, 2010 at 02:47:20PM -0500, der Mouse wrote:
 > >> (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).

Well, it's not in that the curses library would no longer emit escape
sequences, and the curses code that does emit escape sequences would
no longer be in the curses library or in any application library.

But I guess that depends on what exactly one means by "curses", which
isn't uniquely determined.

 > > 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.

Back in the day, such mice were bastardized tty devices, or at least
had a struct tty in the works. I don't know to what extent that's
still true. If it's not, that constitutes progress.

 > > 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.

Maybe. Note that this way you get quite a bit more flexibility to
customize the updater to the terminal if you want. If it mattered
enough you might arrange to pass application-specific hints through,
too.

 > 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.

Right.

 > > 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.

Not for the console, unless you want to give up being able to run vi
on the console. That doesn't seem like a good tradeoff, given that
serial consoles (unlike traditional terminal hardware) are still very
much in use.

 > 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.

No, but it's not that bad. It's basically a form of framebuffer
device, and there's plenty of precedent for that.

 > > 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.

Hardware drivers do! :-)

But, "appropriate" means ten different things to five different people;
all I really mean to say is that it's not implausible and it's not a
complete abrogation of all principled design.

 > >> 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.

Of course not. However, if you want to deprecate something and make it
stick, you have to take a firm line.

Otherwise, the crap hangs around forever, like od(1).

-- 
David A. Holland
dholland%netbsd.org@localhost