home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / unix / 529 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  1.3 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: gwyn@smoke.brl.mil (Doug Gwyn)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: IMPORTANT: POSIX threatens our use of l
  5. Date: 23 Jan 1993 18:35:27 -0800
  6. Organization: U.S. Army Ballistic Research Lab, APG MD.
  7. Lines: 20
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <1jsv9fINN2fe@ftp.UU.NET>
  11. References: <1993Jan21.100223.17722@onionsnatcorp.ox.ac.uk> <1jmq5oINNfna@ftp.UU.NET> <1js17fINNenp@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  16.  
  17. In article <1js17fINNenp@ftp.UU.NET> davecb@nexus.yorku.ca (David Collier-Brown) writes:
  18. >  I'd like to follow the implied RFC model a bit closer and define a
  19. >protocol.  You know, like ``first you open the file, then read or write
  20. >for a while, then close''.
  21.  
  22. Well, gee, once you look at it that way, the spooler interface ought to
  23. be something like:
  24.     cp print_me /dev/spool
  25. where the /dev/spool filesystem takes care of assigning unique queue names,
  26. etc. and for example
  27.     ls /dev/spool/status | grep "^$MY_UID"
  28. would show how your jobs are doing.
  29. Of course that's a bit simplistic, but why should we even THINK about
  30. introducing a new, different protocol for some set of open/read/write/close
  31. actions when we already have a general one?  (Or should have.)
  32.  
  33.  
  34. Volume-Number: Volume 30, Number 39
  35.