Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: mark@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V
Message-ID: <2187@cbosgd.UUCP>
Date: Sat, 31-May-86 16:40:44 EDT
Article-I.D.: cbosgd.2187
Posted: Sat May 31 16:40:44 1986
Date-Received: Sun, 1-Jun-86 09:42:38 EDT
References: <691@bu-cs.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 55
Xref: watmath net.unix-wizards:18233 net.unix:8014 net.info-terms:1008

Why not compile termcap?  Well, if you did compile termcap, you'd
probably come up with something essentially the same as terminfo.
The padding and parameters would be different, but otherwise it
would be very close.  (Time to interpret tparm strings is not
really an issue.)

You ask why a 750 should matter now.  What about all those folks
out there with IBM PC's, 1/4 of a 750?  What about all the Sun 2's,
which are 1 750?  What about the 3B2/300, and the varous 68K boxes
and 68010 boxes, and NSC boxes?  They all tend to be in the 750
performance range.  I can assure you that a difference of half a
second or so of real time to start up vi makes a big difference
in perceived response.  Also, that was 1/4 second of CPU time on
a 750 with a 1982 termcap description.  The descriptions are getting
longer, as more function keys and other capabilities are added.
"Quadratic" gets worse real quick as things get bigger.  (Oh, by the
way, cbosgd is still a 750, and with no way from DEC to upgrade it,
it will likely always be a 750.)

Yes, there are some differences and incompatibilities.  Termcap
was running out of room for expansion.  With only two chars for
capability names, the names being chosen were no longer mnemonic.
The padding conventions (leading digits) were unable to describe
some things that needed description, such as visible bell, resulting
in various kludges that didn't work well (inserting a fixed number
of pad characters, guessing at the baud rate.)  But the real killer
was that tgoto had room for only two parameters, and the parameters
were backwards.  There was no way to handle complex terminals that
needed tests and arithmetic.  There was no way to handle features
like combined attributes, or windows, because these capabilities needed
more than two parameters.

Finally, there was the expectation on my part that I would be able to
take the resulting terminfo, give it back to Berkeley, and it would
naturally take the place of termcap.  I expected termcap to be dead
within a year or so.  This was in 1982, when AT&T wasn't so gung-ho
about proprietary software, or so intent on pushing System V as a
standard.  It has since turned out that Berkeley can't include it
without requiring a System V license, which they were unable to do
for unrelated reasons.  And there are enough places out there running
derivitives of ancient versions of UNIX (including Xenix, for example)
that just get termcap by default.

Since I thought termcap would be dead quickly, I didn't worry as much
about compatibility as I should have.  This is unfortunate, and with
20/20 hindsight, we all realize what we could have done differently.
As it stands, terminfo does have the distinction of being designed
strictly on "best technical" grounds, with no compromises for compatibility.
Once the licensing issues are taken care of, and once SVr3 is widely
available (with the infocmp utility) these pains will be greatly eased.
If I had my way, I'd just post it to mod.sources, but of course, I'd
quickly be looking up the wrong end of a lawsuit, not to mention an
unemployment line.

	Mark