FreeOffice Proposal

[Micah Yoder <yoderm@geocities.com>]

OK folks, you heard it here first.  I've been doing quite a bit of
thinking about getting together a free office suite that would give
Microsoft some headaches.  Here are my first mumblings on the subject...

I realize that SEUL's primary goal is not to develop software, but it is
our goal to make it easier to get people transitioned to Linux.  I
belive this is an integral part of that goal.  FreeOffice could be
"guided" by SEUL and/or spun off as a completely seperate project.

WHY???
------
While there are existing free projects to produce word processors,
spreadsheets, and databases, I feel that they are all lacking in several
areas:  Ease of use, programmability, integration, extensibility, and
workgroup support.

A free, top quality office suite would undoubtably turn much more
attention to the free UNIX community.

BASIC COMPONENTS
----------------
1.  Applications
   -- Word Processor / Web Page editor / Form designer (pretty much
rolled up as one)
   -- Notebook style Spreadsheet - with tightly integrated modules for
budget/expense planning and other specialty spreadsheet applications
   -- Flat file database - could be simple in the first release,
primarily used for data merge in the word processor.
   -- Charting program
   -- (not essential for first release) Presentation Graphics

2.  Integration Components
   -- Macro programming language specification
   -- TCP/IP based protocol for workgroups editing the same document
   -- Modem connection module (so two home users could collaborate on a
document)
   -- Project Manager (organizes several documents as a "project")
   -- Data Manager (to import data from Postgres, MySQL, etc)

ARCHETECTURE NOTES
------------------
I figure that we would have an abstract class called
FreeOfficeApplication.  It would provide as much functionality as
possible:

 - All or most of the File, Edit, and Help menus
 - Common dialog boxes for Open, Save as, Print, etc
 - Macro record/playback / Internet & modem connectivity (essentially
the same, see below)

[more??]

Widget set:  Probably GTK/GTK--.  I *really* think it should be done
with C++.  Hopefully GTK-- will mature quickly.

The entire suite would need to be heavily multithreaded.  Not only so
that things such as printing could occur in the background, but also so
that different users and macros could edit the same document at the same
time.  I know, this could get hairy...

All functions in each program of the suite would have an associated
"command code".  This would probably be a 2 byte code with an action,
followed by its required parameters.  All commands and parameters would
be described in a specification file.  (Sounds stupid? Bear with me...) 
A file might look something like this:

Application WordProcessor:
0:TypeText(String)

This specifies that the word processor command 0 0 (real "null" zeroes)
followed by a null terminated string, when sent to this word processor
document, would insert the string into the text.

This would be used both by the macro system and the workgroup system to
store actions and send actions to other computers, respectively.  But
why the description file?  So that any programming language could be
used to write macros for the thing!!!

I envision a program to take such a code description file and turn it
into a Perl module that would define the TypeText function, along with
all the other functions needed to control the word processor.

But not just that - an IDE for macros could be written to read the file,
present lists of commands and parameter help for the programmer, based
on which application he is programming for.  Basically, any program
could be used as a macro playback system - all it needs to do is open a
socket to the application, send the appropriate codes, and read
responses.  Also a possibility is a central connection manager so that
macros and workgroups could all control many apps (word processor,
spreadsheet, etc) with one macro or connection.

Each application (probably the FreeOfficeApp class) would keep track of
all connections currently open to it - TCP/IP, modem, or macro
recording.  Every time the user does something to the document, the app
would convert it into the proper code and send it to all recipients.

Each incoming connection (TCP/IP, modem, macro playback) would have its
own thread and position in the document.  This means that a macro could
work with one part of a document while the user edits another.  (or a
macro could be attached to the user's console, making him wait for it to
finish.)

EXTENSIBILITY
-------------
Each app would need to have plug-in capabilities.  Each plug in would be
able to store its own data in its own format right with the application
data.

One application for this I immagine is an integrated
math/algebra/calculus system integrated right into the word processor! 
Sort of like Mathematica (but I'm sure we couldn't outdo them. :-( )  I
think it would be possible to come up with a pretty neat math package
though.

CONCLUSION
----------
I have a few more ideas, but that's all for now.  What do you think???

Comments, please!  :-)

And I hope I was somewhat clear about what I meant...I'm just using
Netscape Mail to write this...I didn't formally think all the wording
through yet.  :-)
-- 
"win95 n. 32 bit extensions for a 16 bit
patch to an 8 bit operating system originally
coded for a 4 bit microprocessor by a 2 bit
company that can't handle 1 bit of competition."