Specifying Office Component IDL?

[Ryan Muldoon <rpmuldoon students wisc edu>]

I've been reading this list for a while, and thought that now that
perhaps the discussion wasn't heading in the right direction.  So, I
decided to suggest a direction that might be useful for the gnome office
effort.  

Basically, the GNOME office suite, to come close to being able to
compete with MS Office, is going to have to be built with a component
architecture.  I don't think anyone is debating that.  Bonobo is what
GNOME uses for its component system.  One of the things I find cool
about CORBA is that you can write a set of interfaces in IDL, and then
anyone can write a component that implements those interfaces.  Ideally,
either the packager or the user decides which component to use for each
interface, and this can be changed whenever.  This seems like a good
thing.

So, why am I saying all of this stuff when probably everyone else on the
list knows more about CORBA and bonobo than I do?  Because I think that
rather than deciding what *applications* are going to be in GNOME
Office, we should be thinking about what *Interfaces* we want.  The rest
is just an implementation detail.  Most people won't give a damn whether
it is an Abiword component or a OpenOffice component that they are
typing into for their word processor - they just want the
functionality.  While all the various possible future parts of GNOME
Office are trying to get their next major releases out, a lot of
specification work could probably happen in parallel.  

It seems to me that some reasonable steps would be the following:

1. Determine what interfaces we need (ideally, at a fair level of
granularity) *
2. Discuss needed features of each interface (I'm sure that the members
of the various projects will have a great deal of knowledge on how each
interface will need to be used)
3. Implement IDL for these interfaces
4. Write components that implement these interfaces

* for number 1, I was thinking along the lines of: Equation Editor,
Spell Checker, Grammar Checker, Thesaurus, drawing, file import/export,
printing, document editor, database access, Color picker, etc.  
At each stage, there are probably certain people with more expertise
than others who might be willing to serve as coordinators for organizing
information, reviewing, making suggestions, etc.  

The main rationale I have for wanting to do things this way is that it
seems like numbers 1 and 2 are great for this mailing list to discuss,
and get lots of opinions on what is needed, etc.  It seems like there is
plenty of expertise with the people on this list, and the Sun people
that aren't on this list.  For number 3, there are lots of people in the
GNOME community that can write IDL, and verify that it all makes
sense.  Once we have this done, 4 would almost be trivial.  The nice
thing is that we would have a whole ton of people that would love to
help out on GNOME office.  If they could work on an isolated component
that is clearly defined, they would be more apt to get involved than if
they had to learn a huge codebase.  Also, all the individual components
will be generally useful to other applications.  That seems like a good
way of organizing the development of the Gnome Office suite.

Hopefully this is of some use,


    --Ryan