According to Simon Burge:
>
>The main reason for looking at ncurses was that it is currently actively
>maintained, and that it had changed maintainers and was still going
>forward.  BSD curses didn't appear to be at that stage.  It also was at
>the stage (or close too) of standards compiliance.
>

Julian and I are working towards standards compliance as a goal.  We
are looking at what functions would serve NetBSD best by being
implemented first.

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

I do not believe that this will be a problem :-)

>The argument of "terminfo databases taking up loads of inodes" is an
>implementation issue.

Just for the record, I simply think the "normal" way the terminfo
database is implemented is ugly (just my opinion ;-).  It has the look
of a "good idea at the time" and there would need to be very strong
arguments for perpetuating it which I have not seen yet.

>I like Christos' idea of a new threaded-friendly API,

So do I, so much so I think I shall implement it.

> but I think we
>need the old API to handle >1kB termcap entries without the need to
>change third-party source.

Hmmm I was thinking of just leaving the old calls as wrappers and
truncating the termcap entry at the 1023 mark.  Currently tgetent does
force a truncation.  If the termcap entry is ordered right then the
"important" capabilities should be below the limit and the larger
capabilities, such as colour support, are at the end.

>  Something that comes to mind is to store a
>pointer to a larger buffer (if needed) in the last sizeof(ptr) bytes
>(maybe preceded by a magic number of some sort) at the very end of
>the user-supplied 1kB buffer.  User supplied code scan still manually
>look at the first 1kb-sizeof(ptr)-sizeof(magic)-NUL characters of the
>buffer - I'm sure I've seen some game source do this instead of using
>tgetstr(), tgetnum(), etc.

And still have all the capabilities for people who use the library
interface with the old calls.  I think that this could work.

>  I guess that this has the drawback of memory
>management - at the moment the user doesn't have to tell the library
>when it's finished with the termcap buffer...  If you like this idea I
>can work on it more (more than the few minutes I just put into it!).
>

This is true but the drawback is small since a) the termcap entry is
not likely to be huge, I would say less than 10kB and b) tgetent is
not normally called more than once in the life of a program.

>If we are going to junk of the idea of ncurses altogether, maybe it
>would also be worth adding a terminfo API as well.  This may be of
>limited value (most code probably starts out as termcap based), but
>you never know.
>

I was thinking of adding the terminfo api.  I did propose before that
both the termcap & terminfo functions could reference the same
capabilities database and spit back the appropriate response style
depending on the call used.

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

Needless to say both Julian and I are keen to get BSD curses up to
scratch.  Any help and/or suggestions are most welcome :-)

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================