From derek@knosof.uucp Sun Jul 17 21:22:24 1994 Received: from eros.Britain.EU.net by dkuug.dk with SMTP id AA08648 (5.65c8/IDA-1.4.4j for ); Sun, 17 Jul 1994 21:22:24 +0200 Received: from pyra.co.uk by eros.britain.eu.net with UUCP id ; Sun, 17 Jul 1994 20:22:15 +0100 Received: by knosof.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA03379; Sun, 17 Jul 94 19:56:12 BST Date: Sun, 17 Jul 94 19:56:12 BST From: derek@knosof.uucp (Derek M Jones) Message-Id: <9407171856.AA03379@knosof.UUCP> To: wg15@pyra.co.uk X-Charset: ASCII X-Char-Esc: 29 All, >Date: Fri, 15 Jul 94 13:23:39 EDT >From: stephe@mks.com (Stephen Walli) > >POSIX.1's scope states that it >`` defines a standard operating system interface and environment >to support application portability at the source-code level. >It is intended to be used by both application developers and >system implementors.'' > >The intended users of POSIX.1 are application developers and system >implementors. Not purchasers of applications and platforms. So I guess 1003.3 have been wasting their time. Just because a standard is developed with an intended audience in mind does not preclude other interests using it. > >As a customer of an application, I would like to know that: >-- it runs on every platform upon which I wish to install it. ... But can you say today what platforms you will be interested in tomorrow. Software vendors showing some level of proof of conformance to POSIX are likely to have fewer porting problems than those who don't investigate the issues. Vendor proof of conformance provides a feel good factor to customers that there are no hidden purchasing problems (software not available on platform X) ahead. Also how are you the customer? If you are buying source code along with the binary then conformance is probably of great importance. > >Application vendors that use portability models based on portability >standards will likely have an easier job porting their software. >This is a business decision that they care about, >especially if you are telling them you are purchasing applications >that run on platforms because they support these particular standards. > Yes. I think it is important that we separate out the internal software engineering portability issues (which if done right will save a compnay lots of money) from the marketing issues "Our software conforms to Open Systems standards". >It would be a terrible waste of my tax dollar if my country's >government started spending money supporting any sort of application >conformance testing and certification program. It would be a bigger waste of your tax dollar if they bought applications that did not conform and later had to pay through the nose to change vendors or have them ported. Given that NIST is already up an running the incremental cost of adding applications testing is small. I have yet to hear of the US Government directly funding develoment of test suites. >Likewise, >it would be a disservice to national application vendors to insist they >develop completely conformant (certifiable) applications. >This will cost them money to develop applications >that are conformant rather than competative, >and I would rather the software industry was healthy and paying taxes, >and paying software developers like me (so that I may unfortunately pay taxes). > Again this is a business issue. The advantage of a testing service is that it offers an independent assessment of the claims being made by applications developers. Conformance to standards is one of many priorities that purchasers have the weigh up before deciding what products to select. >It would be a special kind of disservice to POSIX to try to >``put teeth into it'' for application conformance. >This will thrust it once more into the middle of a marketing battle, >because once more it will be perceived as a threat rather than a tool >by vendors. So why does POSIX go to such lengths to define the concept of applications conformance? Given that most vendors claim some sort of conformance to standards this issue of obviously important. The only threat that I see is that many claims will be shown to be not worth the hot air taken to say them. Don't purchasers really want to have some means of independently verifying vendors claims? > >POSIX.1 is an excellent base for a portability model, >used in conjunction with ANSI/ISO C. One can even write useful and >interesting applications using just these two standards. >One will likely want to expand their model to include specifications >(standard or otherwise) for a GUI API, possibly a GUI look-and-feel, >and a network IPC mechanism. This immediately puts the >application at odds with just POSIX.1 and its amendments, >with respect to applications conformance. The existing POSIX conformance model handles this situation. There are various places where things could be fine tuned. Lets not throw the baby out with the bath water. > >POSIX.1 is a source code portability standard. It is to be used >by application developers writing source code. It needs to be implemented >by system implementors on their architectures to be useful to those >application developers. It extends a useful portability model. >I believe discussions of POSIX.1 applications conformance and >testing and certification are nasty consumers of resources >(people and time), that offer no genuine benefit. > The same thing might be said about standards. But having decided to create a standard I think a responsible committee would also look to see that claims of conformance could be tested and ought to encourage work to carry out such testing. derek jones ps. I shall be leaving for a WG14 meeting in 12 hours (yes it is 9 days away, but ...) so will not be able to follow up any responses to this posting.