[ On Saturday, April 24, 1999 at 23:37:27 (+1000), Simon Burge wrote: ]
> Subject: Re: A solution for termcap lossage? 
>
> A major stumbling block for ncurses was that it's internal terminfo
> representation didn't allow for extension to terminal attributes.  For
> example, you couldn't add a "zz" capability, even when in "termcap
> compatibility mode".  The current maintainer has stated that this will
> be a goal _after_ the next release of ncurses.

If you can seriously find something that *really* needs a new capability
in order to be made to work -- i.e. something critical to the correct
operation of a screen-based application, not just some new and fancy
bell or whistle -- I'll be really surprised.

Of course if extensibility really is necessary then yes, it really does
have to wait until a major release comes around.  Either that or you
fork the project and hope the old way is eventually supplanted entirely.

> The argument of "terminfo databases taking up loads of inodes" is an
> implementation issue. ncurses is happy to run with just a termcap file
> (or termcap.db - it can use getcap() and friends).

Actually that argument is only really relevant in a historical
perspective.

I've got so many spare inodes in all my 4BSD filesystems that it's just
not funny (on a SunOS-4 system that already has terminfo installed I've
more free inodes than kbytes of disk space on /usr!!!!) -- I could have
a 100 terminfo databases and not even notice.  This argument *only* ever
applied with SysV's filesystems.

But, yes, if it all those little files bother you then you can indeed
trade inodes for CPU cycles.  Cap_mkdb gets rid of the I/O access
problems with a termcap files, but it doesn't eliminate the processing
overhead.  If you really look at how these kinds of databases are used
you'll find that DB files are overkill and that a simple search through
the filesystem is more than effective enough, especially when you
consider that ordinary filesystem caching will make such accesses more
efficient the more frequent they are.

What's really important here isn't the efficiency though -- it's the
ease of management.  The administrator never needs to wander through
the database hierarchy -- the tools do it all transparently.  The only
tool I ever found lacking was some way to delete old entries, but that's
quite a rare operation and not all that difficult with ordinary file
management tools.

> I like Christos' idea of a new threaded-friendly API, but I think we
> need the old API to handle >1kB termcap entries without the need to
> change third-party source.

Hmmm.  Yes, thread support will be necessary no matter how little anyone
like myself dislikes user-level threads.

As for handling >1KB termcap entries, well, one could argue that this is
an API limitation that's been there from day one.  One could also argue
that the application (screen in this case) was buggy and needs that fix
too, regarless of platform.  I don't know all the history with this
particular issue, but I've fought with it before on commercial platforms
and it's nothing new.  I never really worried about termcap's >1KB
because I could always migrate to terminfo, and I've always treated that
as an inherent limitation.  I suspect the API could be fixed without
introducing too much incompatability, but I'm not sure why it needs to
be -- do termcap entried really need all the function keys defined?  How
many applications really make use of all those bells and whistles?

> It doesn't worry me either way if we move to ncurses or update BSD
> curses.  As long as we're moving forward, I'm happy (and happy to help
> either way)...

I'd rather move forward with the most "bang" for the effort, and ncurses
seems to be the way to get this by many orders of magnitude.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>