Re: How do we want the different parts to integrate (Was Re: What goes in gnome office? (Lets keep it simple))

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2002-04-17 at 08:52, Mikael Hallendal wrote:
> ons 2002-04-17 klockan 00.29 skrev Rodrigo Moya:
> > On Tue, 2002-04-16 at 23:40, Mikael Hallendal wrote:
> > > 
> > > Well, this is just a try to get the discussion started on how we really
> > > want the different parts to integrate. If we know that it's much easier
> > > to start figuring what's the shortest path to get it.
> > > 
> > I think we should define some generic way of integrating apps, not only
> > specific ways (accessing Evolution from MrProject, GDA plugin in
> > gnumeric, etc). Having some generic way of making 2 GO apps talk very
> > easily, without knowing of each other.
> > 
> > Of course, specific 'plugins' are also a good idea, since they give more
> > features and integration, but having some generic way of sharing data
> > might be nice.
> > 
> > For this, it seems Bonobo is again the best option, since we could:
> > 
> > * allow communication of apps via known interfaces.
> > * embed graphics made in 1 app into another (MrProject's graphs,
> > GNOME-DB graphs, Gnumeric graphs, etc)
> > * embed *any* GO document into any GO app
> 
> Yes I agree, having special interfaces between each app is not a
> solution. What I meant was just that if we try to identify the things
> that we'd like to do it will be easier to identify generic interfaces.
>  
from the top of my head, we could want to:

* get streams of data from apps -> equivalent to BonoboStream and
friends
* embed documents from one app into another -> BonoboEmbeddable
* embed dynamic graphics -> BonoboControl
* automation -> custom IDL, such as the one available in MS Office's
VBA, where you've got an object called Application which lets you manage
from your code *any* msoffice app. Then, each app has its own interface,
but all of them implement the basic one.
* be able to generate documents of one type from another app, via
automation -> custom IDL/plugin system
* get rows of data -> custom IDL/plugin system or reuse GDA IDL, which
already define a way for that. This could be used to get data from a
database via GDA, and also for getting all the info in the evolution
addressbook/calendar, for instance.

> > Of course, we could just use a simple plugin system (shared libraries),
> > without Bonobo at all, but, at the end, what we need is a set of common
> > interfaces (CORBA or non-CORBA) so that making GO apps talk to each
> > other is easy.
> 
> non-CORBA! non-CORBA! non-CORBA! :)
> 
I understand some people don't like CORBA, and I also understand there
are some problems for multi-platform apps if using CORBA, but, if we
want some integration right now, the easy way is to reuse all the stuff
that has been done in Bonobo. Not doing so will mean, IMO, reinventing
some of the stuff done in Bonobo in a different architecture (shared
library plugins or whatever). So, unless the replacement of CORBA/Bonobo
for all this is already available and fully tested as Bonobo has been in
the last year or so, I think we should stick with CORBA/Bonobo. Even
Abiword, which was one of the last GO apps that didn't use Bonobo uses
it now :-)

cheers
-- 
Rodrigo Moya <rodrigo gnome-db org> - <rodrigo ximian com>
http://www.gnome-db.org/ - http://www.ximian.com/