home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!not-for-mail
- From: davecb@nexus.yorku.ca (David Collier-Brown)
- Newsgroups: comp.std.unix
- Subject: Re: IMPORTANT: POSIX threatens our use of l
- Date: 23 Jan 1993 10:02:23 -0800
- Organization: York University
- Lines: 31
- Sender: sef@ftp.UU.NET
- Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
- Message-ID: <1js17fINNenp@ftp.UU.NET>
- References: <1993Jan21.100223.17722@onionsnatcorp.ox.ac.uk> <1jmq5oINNfna@ftp.UU.NET>
- NNTP-Posting-Host: ftp.uu.net
- X-Submissions: std-unix@uunet.uu.net
-
- Submitted-by: davecb@nexus.yorku.ca (David Collier-Brown)
-
- geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
- >Maybe we should just define a printing API. Nail down a really
- >straightforward interface (just half a dozen calls or so), then divvy
- >up the work to create a SunOS shared lib for Solaris 2.x, plus one for
- >SunOS 4.1.x, a DLL for MS Windows, a static lib for BSD386/386bsd (and
- >linux?), one for Ultrix etc. Thoughts?
-
- I'd like to follow the implied RFC model a bit closer and define a
- protocol. You know, like ``first you open the file, then read or write
- for a while, then close''.
- A little more formally, `` open [read*|write]* [seek [write*|read]] close''.
-
- An API is necessary and about two thirds of sufficient. A protocol is
- odd-loking, but sufficient. To make it more palatable, you could easily
- include a call interface in a common language.
- The advantage of doing the extra work is in making any ordering, temporal
- effects and prerequiesites explicit. This leads to easy implementation of
- programs using the interface.
-
- --dave (who is notably lazy, and so goes to great lengths
- to avoid future work) c-b
- --
- David Collier-Brown, | davecb@CCS.YorkU.CA | lethe!dave
- 72 Abitibi Ave., |
- Willowdale, Ontario, | York postmaster and
- CANADA. 416-223-8968 | occasional sendfail(8) consultant.
-
-
- Volume-Number: Volume 30, Number 38
-