But with terminals, you can't really say which standards are acceptable 
to NetBSD.
It's probably not even relevant. If someone comes with a certain 
terminal, that's what he got to play with, no matter what standard (or 
none) that the specific terminal happens to adhere to. And looking at a 
manual page on possible terminal standards will either point him to 
something that is (probably) irrelevant to him, or is so extensive that 
it covers all that the termcap library do, which means it will be larger 
than huge.

 From a NetBSD point of view, the only interesting thing is if we can 
support it or not. Preferrably we can. No matter what that terminal 
speaks. And the way we do that is via the termcap library, which covers 
exactly how each different terminal do things, or what exact 
capabilities a specific terminal have.

That's the point I'm making. If we choose to say that ANSI is the 
standard we follow, does that mean that we should stop handling all 
other terminal models? Because we can't change those terminals to start 
being ANSI. And if someone wants to know how to get a specific effect on 
the terminal that he happens to have, ANSI might just be totally useless 
to him, just as it might be just what he was looking for.

(Och, and if termcap really is termlib these days, please substitute as 
approriate. I don't really follow that development.)

I'll be quiet now. I promise. ;-)

	Johnny

George Georgalis wrote:
> On Tue, Oct 03, 2006 at 11:28:17PM +0200, Johnny Billquist wrote:
> 
>>I think the first thing to realize that is is rather much outside the 
>>scope of NetBSD.
> 
> 
> I see that. but I don't entirely agree. How can programmers or
> users be expected to conform to or utilize a standard when it is
> difficult or impossible to know where to look or to even know if a
> standard exists?
> 
> After using netbsd for nearly two years, one thing I appreciate
> over Linux (where I have most of my experience) is adherence to
> best practice (and presumably standards). In Linux it seems like
> somebody reinvented the wheel around every corner.
> 
> If a guideline where available as to which standards are
> acceptable for netbsd, where and when they are used, where they
> came from, and what they are authoritative for; where they are
> published and where reasonable or possible, even included; that
> would go a long ways to getting everyone on the same page--I'm
> not suggesting a finite set of standards should be used or people
> should be discouraged from making up their own, rather the
> established standards could be more visible.
> 
> 
>>Second, the ANSI standard isn't the only way of doing things.
> 
> 
> I understand that, what I'm describing is a means by which
> developers and users can use to make an educated decision on
> which standard is appropriate (vs not knowing if a standard was
> available at all).
> 
> 
>>The 
>>termcap is a fairly good source of information, even if it isn't complete.
>>But the termcap file is huge! But I would say that is a good place to 
>>start if you want information, unless you want to read standards that 
>>might or might not be relevant for you.
> 
> 
> I'm thinking more about regulated deployment than my immediate
> needs.  A STANDARDS section of man pages to describe which
> standard(s) the author used (and where to find them); along with a
> standards(5) page to summarize the most common choices available.
> 
> 
>>Terminals exist outside of NetBSD. It's like if we would start 
>>documenting how RS-232 works in NetBSD, just because we happen to have 
>>serial ports.
> 
> 
> I appreciate netbsd is not authoritative for most of the standards
> it is built on, but if a path for discovery was begun, well it
> would be a lot easier to make serial devices or drivers.
> 
> Your description of POSIX, ANSI, ISO relationships was
> informative, Johnny.  Disclosure of relevant standards, who is
> authoritative over them and their hierarchy would be a valuable
> addition to netbsd, in my personal opinion. :)
> 
> // George
> 
>