From stephe@mks.com Fri Jul 15 09:23:39 1994 Received: from mks-gate.mks.com by dkuug.dk with SMTP id AA16685 (5.65c8/IDA-1.4.4j for ); Fri, 15 Jul 1994 21:19:17 +0200 Received: from mks.com by mks-gate.mks.com (8.6.8.1/MKS-1.1) id NAA01582; Fri, 15 Jul 1994 13:23:41 -0400 Received: by mks.com (4.1/GIGA-1.2) id AA18780; Fri, 15 Jul 94 13:23:40 EDT Date: Fri, 15 Jul 94 13:23:39 EDT From: stephe@mks.com (Stephen Walli) Message-Id: <9407151723.AA18780@mks.com> To: D.Cannon@exeter.ac.uk, sc22wg15@dkuug.dk Subject: Re: (SC22WG15.363) Posix Apps conformance Content-Length: 6695 X-Charset: ASCII X-Char-Esc: 29 Hello All, I am a little concerned by the opinions expressed in the letter from the British National Health Service, and statements of support for this point of view from colleagues in the POSIX community. I would like to offer a different view on the NHS's concerns, and why they and others in similar situations may wish to take a different approach to the problem. 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. As a customer of an application, I would like to know that: -- it runs on every platform upon which I wish to install it. -- I want to know that the application users do not need retraining when they use the application on a different platform. -- I want to know that data created by one instance of the application on one platform can be used by another instance of the application on another platform, possibly across a network, although there are many reasons why it may not *need* to be supported across platforms. I do not care one little bit about whether or not they used POSIX.1, ANSI C, Tcl/Tk, or any other *implementation* technique. I want it to work. Prior to POSIX.1 and ANSI C existing, many application vendors, of applications such as relational databases and system analysis tools, offered tools on multiple platforms. How they did this was of no concern to me as a user of these applications. One might not even care about the number of platforms an application runs on, if one lives in a networked environment where one can run the application on a single machine in a window on an X-terminal. (This becomes more an issue of what a vendor charges per licence, and whether they charge different amounts for licences on different machines.) As a large purchasing agent, such as I am presuming the NHS is, I would probably encourage my application vendors that I am purchasing particular platforms, based on particular criteria, and that I will put my application dollars where my platform dollars are going. I would point out that the particular criteria is platforms that support POSIX.1, ANSI C, window manager foobar, and so on, but this is information that is helpful, not necessary. It allows your supplier to understand what platforms you, their customer, feel are important, and where you will likely place your platform dollars in the future, so they themselves can begin making future plans. How the application vendors choose to implement their applications on those platforms, current and future, is their business. As an example, you certainly would NOT want to have a relational database vendor create a product that was SLOWER by necessity to make it conformant, by insisting they use certain conformant calls rather than using their own knowledge of how a pariticular architecture accomplishs certain things. Indeed, if they came to you beforehand, because you were a good customer, and said: ``We *will* deliver it on platform Y, but we can make it 15% faster if we don't have to ensure the application uses only standard Z's calls.'' What would you tell them? You don't care how. You care that they deliver it on platform Y. You want to be able to buy the application. Indeed, they would likely choose application speed over conformance without asking you because they need to remain competative against other vendors selling similar applications, and you are but one customer. 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. 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. 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). 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. 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. Currently, I work for an application vendor. We know a lot about POSIX, as we sell POSIX.2 and implement it using POSIX.1. But, just because I have machines that implement these specifications does not mean that my entire application base uses them. There are places where we need to deliberately, by design, write non-portable code. My application architecture is such that I still know where those pieces of source code are. My application portability model also takes into account the tools and process I need to manage and build my application source across all the machines I need to support. 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. My two cents. Kindest regards, stephe ------------------------------------------------------------------------------ Stephen R. Walli, stephe@mks.com | Walli's Second Law of Nature: Mortice Kern Systems Inc. | We're higher on the food chain. phone: +1 (519) 883-4314 ** NEW ** |