🚀 go-pugleaf

In article <1992Aug19.143528.9405@mic.ucla.edu> iwelch@agsm.ucla.edu (Ivo  
Welch) writes:
> 
> I have been trying to  convince Athena  Design to include a Unix   
command-line
> file reader. That is, a utility  that reads a  Mesa spreadsheet and  
outputs an
> ASCII data file (i.e. a command line equivalent of "save as text"). That  
would
> allow me to use Mesa to keep all my databases,  and  to  have  S or  
other Unix
> filters operate on a  database; or to dial  in and look  at the contents  
of my
> spreadsheets. (Even nicer if  there was an  update  mechanism.) Note  
that this
> cannot be accomplished through Mesa's API.
> 
> Athena Design sees no demand for this  feature, although it would  
require only
> minimal effort to implement.   Perhaps  more  requests could  convince   
Athena
> Design otherwise. I very much like their spreadsheet, and would want to  
use it
> for real work.

I'd like to reply publicly to this.

First, from an engineering standpoint, this is not an easy task.  It  
requires more than a "minimal effort."  The part of the program that loads  
worksheets is intimately tied to the display mechanism.  This means that  
we would have to maintain two separate versions of the code and make sure  
that the file loading part worked on both across all versions of the file  
format (numbering 9 at this point, and yes we are still fully compatible  
with all files written since version 0.5 of the program.)

From a logistics standpoint, the concept of having yet another program  
that we have to test every time we do a rev seems to require a lot of  
justification.  Currently, we ship the Mesa program and an example program  
that takes advantage of our object library.  We have to test these two  
program every time we ship a new version (we have been shipping new  
versions at least once a month since May, our next version is due out on  
September 4th and include SQL capabilities and cell shading, not to  
mention dozens of little changes and fixes.)  We take having a solid  
product version seriously.  This is why folks like Preferred Health Care  
have stated that we had the most solid and reliable beta product they have  
ever used.  The justification for having an additional program to test  
every time we ship has to be very strong.

Let's look at the justification.  One person wants to be able to dial into  
his NeXT and use his spreadsheet like a database.  He is an educational  
user, so he will be buying Mesa for less than a hundred dollars.  He wants  
us to add this functionality, despite that Mesa is a NeXTSTEP application,  
despite that no other spreadsheet on the NeXT offers this functionality,  
despite that he could export his files from Mesa while he was using the  
NeXT locally and then access them via modem later.

We pride ourselves on listening to customer feedback.  Customers said, "we  
want a ToolBar."  Mesa has the coolest ToolBar of any program on any  
machine.  Customers said, "we want direct manipulation."  Mesa allows drag  
and drop color and fonts (yes, fonts) to change cell color, shading, graph  
element color, etc.  Customers said, "we want to access our Sybase data  
and pump it into the worksheet."  Mesa now provides full Sybase SQL  
capabilities with unlimited queries associated with each worksheet.   
Customers said, "we want a spreadsheet view in our custom application."   
No problem, and coming with 1.1 you can even edit cells in your custom app  
and have those edits reflected in the worksheet.  Customers said, "we want  
live, editable spreadsheet views in our word processor."  You'll have to  
wait 'til Seybold to see our answer to this.

We would very much like to respond to every user's request for every new  
feature.  We have limited resources.  There are still a number of major  
features we want to add to Mesa (including a cool scripting language, 3D  
charts (both in response to Appsoft Solution, which we view as a very  
solid competitor), infinite level Undo/Redo, a NS486 version, better  
execution of Lotus macros, support for PostScript Level 2, support for the  
DBKit, Excel file capabilities, etc.)  A command-line interface to Mesa is  
just not a high priority.

Finally, I'd like to point out that Mesa has the best database  
capabilities of any spreadsheet.  It fully supports Lotus-type database  
functions, even across linked sheets.  It supports unlimited Sybase  
queries to pull in data from real databases.

To sum up, we want to make Mesa an awesome spreadsheet.  We have and will  
continue to listen to user input and let that guide our development of the  
product.  We have to prioritize the requests for new functionality in  
terms of "how much will this add to the product" and "will the additional  
sales of the product justify this addition" (with much more weight given  
to the first question.)

Ivo, thanks for your feedback.  If you want to get command-line access to  
database information, why don't you buy a database (like Sybase)?

David

-- 
David Pollak - dpp@athena.com - NeXTMail Compliant
Attorney at Law,
Feeder of the Bears, Athena Design, Inc.