Re: gnome-db/TOAD/gASQL (was Re: [gnome-db]Access-like prkect)

[Rodrigo Moya <rodrigo gnome-db org>]

On 27 Jul 2001 13:19:51 +0200, Vivien Malerba wrote:
> On Fri, Jul 27, 2001 at 01:12:57AM +0200, Rodrigo Moya wrote:
> > On 26 Jul 2001 17:50:25 +0200, Vivien Malerba wrote:
> > > On Thu, Jul 26, 2001 at 04:58:36PM +0200, Rodrigo Moya wrote:
> > > > Hi!
> > > > 
> > > > want in GNOME-DB. And this reminded me of another thing, which I've been
> > > > thinking for a while, Vivien, which is to merge the functionality in
> > > > gASQL into GNOME-DB, and make one killer app instead of 2 good apps.
> > > > Also, if we support some of the things that are in gASQL in GNOME-DB,
> > > > we'll make a big pain to gASQL, since I suppose people won't install an
> > > > app that does the same that GNOME-DB, and which itself depends on
> > > > GNOME-DB. I know this means some extra work, and please note that by no
> > > > means do I want to "kill the competition" :-) by merging gASQL into
> > > > GNOME-DB, of course not, but I really think there should be a good app
> > > > for DB access in GNOME (like there is in Windows, with Access, Paradox,
> > > > etc) instead of 2 with redundant functionality, or with stuff supported
> > > > in one and not supported in the other one
> > > > 
> > > > so, should I shut up or is there something interesting in what I say?
> > > > 
> > > 
> > > No, I think this is worth thinking about.
> > > 
> > > When I started gASQL (before I knew about GNOME-DB), I had the same need as you (and I
> > > still have). I decided to use GNOME-DB because it offers a solid foundation and allows
> > > to connect to many databases in the same way.
> > > 
> > > About a possible merging, I agree with you about the fact that we should not duplicate 
> > > our work. I've thought about the respective positions of gASQL and GNOME-DB, and I think
> > > the two products are complmentary. Let me explain:
> > > * about the archutecture: for the two, libgda is the common engine
> > >
> > yes, I've even thought myself to concentrate on libgda and leave
> > GNOME-DB almost as
> > it is, with only some additions
> 
> I would like to move forward more on this part because this is what everything relies on
> (specifically for the MySQL and Oracle providers)
> 
ok, you've almost convinced me. I myself will concentrate on all the
basic
architecture and leave all end user stuff for gASQL.

> > > * work on gASQL to make different components reusable, and bind gnomedb-fe and gASQL more
> > >   closely.
> > > 
> > I can think of 2 solutions based on what you say:
> > * have gASQL as another Bonobo component of GNOME-DB, in the same source
> > tree,
> > etc
> > 
> > * have gASQL as another Bonobo component of GNOME-DB, but having it as a
> > separate
> > program that, when installed, integrates nicely into gnome-db. That is,
> > as we're
> > already using a custom CORBA interface for gnomedb-fe to communicate
> > with the different
> > components, we could have gASQL implement this interface so that, when
> > installed, it
> > is seen as another part of GNOME-DB. That was the motivation when I
> > wrote the CORBA
> > interface, to enable extensions, and gASQL seems like a good extension.
> > 
> > another solution would be to leave GNOME-DB as it is (adding report
> > execution when
> > the report engine is done, and some other little things), and
> > concentrate o libgda
> > (I mean myself) specially. This could even be done in one of the above
> > solutions
> > 
> 
> Right now it is not possible to treat gASQL as a component (it is too much closed on
> itself for that right now).
> 
yes, I know, but I mean, if we decide to go this way, we should work on
making
it a component that implements the GNOME::Database::UIShellComponent
interface

> >From all the above comments, here is what I would propose (in chronology as it is more and more
> work to achieve the different goals):
> * first start by making releases of gASQL at the same time as GNOME-DB releases, with
>   the packages for each located at the same place, so the users can get the two at the same time.
>
yes, as we all agree on this, next release will include gnome-db, libgda
and
gASQL. Also, I'll start making sure gASQL in CVS always compiles with
gnome-db CVS

> * convert gASQL into components which could give something like:
>   - what I called a core 'component' which would take a moniker string (for example
>     "gASQL/home/tests/myfile.xml!Form:my_custom_form") and return a bonobo control for what
>     the moniker represents (in this case a form). I think of the following bonobo controls
>     to be 'rendered': forms, tabular views, reports and SQL versions of some queries.
>     gnomedb-fe will be able to use these bonobo controls
>   - the gASQL application as it is now to create the xml files which will be referenced in
>     moniker strings
> * AND next turn most of the dialogs of gASQL into separate components (this is really a BIG work).
>   At this point the gASQL application as it is now will only be a 'shell' for all the above mentionned
>   controls. This step leaves us with a big 'core component' managing the gASQL data (relationships, etc)
>   and controls exported by this core component and imported from other applications through bonobo (the 
>   perfect multi Model-View-Controler application)
> 
> What do you think of this (the applications structure and the milestones)?
> 
yes, this sounds perfect to me. But I insist in having gASQL export its UI via
the GNOME::Database::UIShellComponent, so that it easily integrates in
gnome-db
when it is installed. In fact, gnomedb-fe, at startup, does a query of
all components
that implement that interface, and loads them, so this is why I think
this is
the right solution.

The monikers idea is ok, but I see it as oriented to other tasks, such
as
document embedding, app developers who want to use gASQL features, etc,
but not 
for the gnomedb-fe.

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