NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/next/software/1274

Text File | 1992-08-20 | 5.4 KB | 112 lines

Newsgroups: comp.sys.next.software
Path: sparky!uunet!gatech!rpi!psinntp!psinntp!dpp!dpp
From: [e-mail] (David Pollak)
Subject: Re: Mesa --- lack of database functionality
Message-ID: <1992Aug20.150304.10018@dpp>
Sender: dpp@dpp
Reply-To: [e-mail] (David Pollak)
Organization: Athena Design, Inc.
References: <[e-mail]>
Date: Thu, 20 Aug 1992 15:03:04 GMT
Lines: 99

In article <[e-mail]> [e-mail] (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 - [e-mail] - NeXTMail Compliant
Attorney at Law,
Feeder of the Bears, Athena Design, Inc.