Re: ANNOUNCE gnome-db (using CORBA)

["Dirk-Jan C. Binnema" <bulkmail dds nl>]

-----Original Message-----
From: Adam Keys <adam@pingpage.com>
To: Dirk-Jan C. Binnema <bulkmail@dds.nl>
Cc: gnome-list@gnome.org <gnome-list@gnome.org>; Michael Lausch
<mla@gams.co.at>
Date: zaterdag 8 augustus 1998 2:16
Subject: Re: ANNOUNCE gnome-db


>Dirk-Jan C. Binnema wrote:
>> I thinks its a great idea to have standardized database access, so good
luck
>> with it. However, IMO, you should _NOT_ have a Gnome specific API!!!!


>If I have my way and get my foot into the code for gnome-db, it will not be
>GNOME specific, except the widgets.  My end goal is to write an
>uber-Access/Paradox app.


This is good! Note that less==better in this case. While Access also
provides
a toy database backend, a _good_ database frontend / app builder (like yours
;-)
should leave the db backend to someone else...
This is the hierarchy I like:
>
>GNOME widgets    any application (KDE, X, Java, Mac, Windows)
> | |
> -----------------
> |
> CORBA client
> |
> CORBA server
>   |
> ODBC
>   |
> database
>
>Thus you could really use any ORB, and not just ORBit, so long as everyone
is
>kosher with everyone else.  This removes the language problems also, so
long as
>there is a ORB available for a given language, that language can interface
with
>the API.
>
>Does this give everyone a happy warm feeling?


Really, this is a Good Idea (tm). And it's even more like MS-ADO,
which you access through COM. So we could use the ADO-API as
a template for the interface our CORBA server object offers. (there's
nothing very special about the ADO API, but it least let's not invent
*another* API, we can have source-level compatibility with a lot
of (higer-level) DB APIs simply by writing wrappers)

I'm not really sure why we should have a separate CORBA client layer,
can't we just let the GNOME-widgets _be_ the Corba-client?
Something  like this:

[Gnoracle/Gnaccess/Gnaradox... ;-)]
    |
[Corba Server (e.g. with "GnADO" interface]
    |
 [odbc]
    |
[database]

Of course, you could use the CORBA client layer to encapsulate CORBA
issues, but is this what we want (kind-of like programming COM in C++ vs
programming in Visual Basic )

As a side note, maybe we could make a _generic_ GNOME lib for encapsulating
CORBA specifics, so programmers don't need to learn anything (well...) about
CORBA, you can have different ORBs, etc.

However, now I'm really entering the area of the stuff Miguel c.s. are
working on. They propose to use some OLE2'ish on top of CORBA for the
communication among apps (like KDE's KOM/Openparts). I'm not really sure
where they would place this. The important thing is that I don't want to be
forced to make a lot of changes in my code, simply because I want to access
my DB over the Net instead of locally....

Concluding, I think you're idea is good, I just hope using CORBA won't be
slowing things down too much. Maybe we can have the same API directly on on
ODBC, so there's always a (faster) solution. Of course, raw ODBC, and even
better raw DB access is even faster, but less flexible.

IMO, any solution we come up with should have the following requirements:
    1) Database access should be DB independent
    2) Database access should be location independent
    3) Database access should be UI independent

For 1) I think we should use ODBC, for 2) & 3) we can use CORBA.
Requirement 3) kind-of makes it hard to use the stuff Miguel c.s.
are brewing... Next to these reqs for flexibility, we can do some optimized
special cases, like direct ODBC access.