Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.26/text0014.txt

Text File | 1992-02-21 | 2.3 KB | 49 lines

Submitted-by: [e-mail] (Scott E. Preece)

In article <[e-mail]> [e-mail] (Sean Eric Fagan) writes:

| Having worked at a company that implemented some POSIX features during and
| after the standardisation process, I know what Dan's saying:  some of the
| things being standardised did not exist until POSIX invented them.  POSIX
| job control, Dan's personal favorite, is similar, but not quite like, BSD
| job control, which everyone else used.
|
| Since it did not exist until POSIX invented it, how could it managed to have
| been tested before it was standardised (and, due to FIPS, required for
| certain key sales)?  There is a difference between standardising what you
| have implemented, and implementing what you have standardised.
---
Yes, but the working group is supposed to be made up of people who
have a lot of experience with the existing art and its implementation
and know (1) what is implementable and (2) what is wrong with the
existing art.  There are enough people involved with an interest in
continuing to sell what already exists that people have to be able to
produce serious arguments (which would translate into responsive
negative ballots) to effect a change.  Usually this means there is
consensus in the group that there are serious problems with existing
approaches *and* there is consensus in the group that the functionality
can't just be left out of the standard *and* what is proposed is similar
enough to existing approaches that the experienced implementors in the
group believe implementation is practical.

Also, of course, it's a long time from the appearance of an interface in
a draft standard to the time the standard completes balloting and is
approved.  In that time people generally do do prototype implementations
to validate their expectations.

While it's almost always better to standardize existing practice than
invent new solutions, there are elements of existing systems that are
universally rejected as inadequate, broken, or mistaken, and it would be
a disservice to the community to standardize things that the group
consensus recognized as bad practice.


--
scott preece
motorola/mcg urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]
phone:    [phone]              fax:    [phone]

Volume-Number: Volume 26, Number 15