Re: tn3270, mset and map3270

[itohy%NetBSD.org@localhost (ITOH Yasufumi)]

In article <4B87EC62.1070900%NetBSD.org@localhost>
roy%NetBSD.org@localhost writes:

> On 26/02/2010 14:30, ITOH Yasufumi wrote:
> > In article<4B866EA0.5030407%NetBSD.org@localhost>
> > roy%NetBSD.org@localhost writes:
> >
> >> What makes you think that terminfo(5) doesn't allow this also?
> >
> > I knew some implementations have extension to allow custom
> > capabilities, but is not portable.
> 
> This does not matter.

An interface is what provides compatibility and portability.

> > Interesting enough, the extension is something like adding termcap
> > entry in the terminfo, and inconsistent with the original idea of
> > terminfo.
> >
> > The idea of terminfo(5) (terminfo(4) might be more precise, since
> > UNIX System V reordered section number) is to use a fixed array of
> > capabilities to speed-up loading database, so basically there is
> > no room for custom capabilities.
>  >
>  > To use custom capabilities, we can use termcap almost everywhere.
> 
> Things have moved on.
> Both ncurses and my implementation allow extensions.

The extension does no benefit to users, at least for now.
One reason is it is not portable.
See below for other reasons.

> > Do you have any benefit to use terminfo for programs that are
> > already written to use termcap?
> > Since our new termcap library is fast, I don't see any benefit to
> > rewrite termcap programs for terminfo.  It just causes loss of
> > features such as $TERMCAP.
> 
> My terminfo implemenation is faster still as it uses hash tables for 
> termcap and terminfo lookups. As the termcap design is to do a string 
> lookup per capability it's always going to be slow. terminfo allows 
> calling known capabilities directly or by going the string lookup route 
> like termcap. It's still quite quick thanks to hash tables.

This conflicts with the basic idea of terminfo: capability names are
not required at run time.  They are only used when compiling a database
source into binary.

Furture, this is a duplication of feature.  Use only one from the table and
string lookup.  Table lookup is terminfo, string lookup is termcap.

> As to re-tooling code in terminfo vs termcap?
> Less code for termcap applications for staters, which means smaller 
> binaries and less memory requirements. Here's a good example of one of 

OK.  terminfo has no functional benefit.

> our applications converted to terminfo
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/atari/stand/edahdi/edahdi.c.diff?r1=1.9&r2=1.10&only_with_tag=MAIN&f=h
> 
> As you can see, it's a lot less code and easier to see what's going on.
> clear_screen means a lot more than "cl".

On termcap, "cl" in programs and "cl" in database.
This is simple and has no confusion here.

On terminfo,
        variable name   capability name
        -------------   ---------------
        clear_screen    clear
        columns         cols
        lines           lines
etc.  As you can see, it is a lot more confusing and prone to mistake.
Users manage to use it since the names are checked on compile time
by C compiler and tic.
However, some terminfo implementations accept extended
capabilities, and users cannot detect their mistake.

For this reason, not accepting extended capabilities
is benefit of normal users.

> Recent updates to my implemation allow
> $TERMINFO="term|alias|term description, cols#80, foo=bar"
> $TERMCAP="term|alias|term description:co#80:foo=bar"

Having more function is not always users' benefit.
Two ways to do the similar thing is not a good design,
since it is confusing.

TERMINFO is undocumented feature of ncurses library;
TERMCAP is compatible with most termcap-capable environments, including
all versions of NetBSD release.
I think we'd better to choose TERMCAP from them.

> What makes you think termcap(3) has gone away?
> We provide a termcap wrapper on top of terminfo :)

So the possible implementations are as follows:

1. have termcap and terminfo libraries/databases separately

   terminfo programs:
        terminfo database -> program
   termcap programs:
        termcap database -> program

2. implement terminfo as an emulation on termcap

   terminfo programs:
        termcap database -> (cap to info) -> program
   termcap programs:
        termcap database -> program

3. implement termcap as an emulation on terminfo

   terminfo programs:
        terminfo database ------------------+
        termcap database  -> (cap to info) -+-> program
   termcap programs:
        terminfo database ------------------+
        termcap database  -> (cap to info) -+-> (info to cap) -> program

Hence my proposal (2 (or 1)).

Why you are going to most complex implementation (3)?

Regards,
-- 
ITOH Yasufumi