home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / software / 1290 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.2 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.172708.406@prim>
  6. Date: 22 Aug 92 17:27:08 GMT
  7. References: <1992Aug19.143528.9405@mic.ucla.edu> <1992Aug20.150304.10018@dpp>
  8. Organization: Primitive Software Ltd.
  9. Lines: 45
  10.  
  11. In article <1992Aug20.150304.10018@dpp> dpp@athena.com (David Pollak) writes:
  12. >In article <1992Aug19.143528.9405@mic.ucla.edu> iwelch@agsm.ucla.edu (Ivo  
  13. >Welch) writes:
  14. >> 
  15. >> I have been trying to  convince Athena  Design to include a Unix   
  16. >command-line
  17. >> file reader. That is, a utility  that reads a  Mesa spreadsheet and  
  18. >outputs an
  19. >> ASCII data file (i.e. a command line equivalent of "save as text"). That  
  20. >would
  21. >> allow me to use Mesa to keep all my databases,  and  to  have  S or  
  22. >other Unix
  23. >> filters operate on a  database; or to dial  in and look  at the contents  
  24. >of my
  25. >> spreadsheets. (Even nicer if  there was an  update  mechanism.) Note  
  26. >that this
  27. >> cannot be accomplished through Mesa's API.
  28. >> 
  29. >> Athena Design sees no demand for this  feature, although it would  
  30. >require only
  31. >> minimal effort to implement.   Perhaps  more  requests could  convince   
  32. >Athena
  33. >> Design otherwise. I very much like their spreadsheet, and would want to  
  34. >use it
  35. >> for real work.
  36. >
  37. >I'd like to reply publicly to this.
  38. >
  39. >First, from an engineering standpoint, this is not an easy task.  It  
  40. >requires more than a "minimal effort."  The part of the program that loads  
  41. >worksheets is intimately tied to the display mechanism.  This means that  
  42. >we would have to maintain two separate versions of the code and make sure  
  43. >that the file loading part worked on both across all versions of the file  
  44. >format (numbering 9 at this point, and yes we are still fully compatible  
  45. >with all files written since version 0.5 of the program.)
  46. >
  47.  
  48. I think there is an easier way to provide this feature. Rather than the
  49. command line tool doing the conversion itself, it should simply use the
  50. Mesa API and send a message to Mesa to say "please save this spreadsheet
  51. file as ascii text" and then wait for the reply.
  52.  
  53. Now surely that's fairly straightforward to implement?
  54.  
  55. Dave Griffiths
  56.