home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / software / 1292 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  1.5 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!unido!prim!dave
  2. From: prim!dave@germany.eu.net (Dave Griffiths)
  3. Newsgroups: comp.sys.next.software
  4. Subject: Re: Mesa --- lack of database functionality
  5. Message-ID: <1992Aug22.185648.1052@prim>
  6. Date: 22 Aug 92 18:56:48 GMT
  7. References: <1992Aug19.143528.9405@mic.ucla.edu> <1992Aug20.150304.10018@dpp> <1992Aug22.172708.406@prim>
  8. Organization: Primitive Software Ltd.
  9. Lines: 22
  10.  
  11. In article <1992Aug22.172708.406@prim> prim!dave@germany.eu.net (Dave Griffiths) writes:
  12. >
  13. >I think there is an easier way to provide this feature. Rather than the
  14. >command line tool doing the conversion itself, it should simply use the
  15. >Mesa API and send a message to Mesa to say "please save this spreadsheet
  16. >file as ascii text" and then wait for the reply.
  17. >
  18.  
  19. Sorry, should have engaged my brain a little more before posting that. The
  20. original poster wanted to be able to dial-in to his NeXT and run the
  21. command line tool. That's the tricky part. (If he was logged on through
  22. the Workspace manager the only problem may be having Mesa displaying the
  23. spreadsheets it was converting, although a good design would seperate the
  24. data retreival/storage from the actual display).
  25.  
  26. My question then: is it possible to launch NeXTStep applications from a getty
  27. (dial up) shell? Like supply a flag to say "don't display the windows for
  28. this app" (a bit like redirecting output to /dev/null). You may say what's
  29. the point?, since the app couldn't receive any mouse/keyboard events. True.
  30. But it _could_ receive messages for it's API.
  31.  
  32. Dave Griffiths
  33.