Re: Proposed: Ghijk

[Peter Norton <spacey inch com>]

On Sat, Feb 07, 1998 at 12:17:26AM -0500, Sergey I. Panov wrote:
>  Patrick Narkinsky:
> > 	1) Display Component: The display component will provide
> > 	   facilities to display data in an "end-user" fashion.  
> > 	   A report generater will also be included in the component.
> 
>   Is it something what one would call DB browser/viewer. As I
> understand it is not going to be frequently used application. But
> specialized frontends, like address book, publication references ,or
> financial information, will be in use all the time.

For some people it's not going to be frequently used - but you have to
view it as the same thing as your favorite filesystem navigation tools.
Under linux (with analagies on other OS'), you don't worry about whether
you're using al minix, ext2, ext, dos, or win95 (long file names).  You
expect that you have your unifying interfaces to all of them: the standard
unix utilities like ls, cat, grep, etc.  I consider this equivelant to a
good database "browser".  Other front-ends may be like mc, the gtk file
selection widget, etc - extensions and wrappers of the system calls the
simpler tools have to make, as well as wrappers around these tools as
well (i.e. emacs' file browser depends on ls).. 
 
[snip]

> Why ODBC? I personally have no experience with it, but my close
> friend, who is [high ranking/highly knowledgeable] Oracle consultant,
> made me think that vendor independent database solution of any type is
> a trap. 

Grrrr.  Don't get me started about Oracle.  No, it's very possible to use
vendor independent database solutions.  NeXT's EOF is a good way to do it,
ODBC makes a simpler layer to target that's far easier then re-writing for
different vendor's CLI's, DBI is a good general solution for perl
developed to hide a lot of the vendor-specific fiddly bits from a
developer and makes switching filesystems easier.  JDBC is another
example.  None of these approaches fixes *everything*.  But it's a lot
better then nothing.

> My understanding is that tables from one data base can not be
> transfered in to another DB in 100% of cases without loss.(He had an
> example when company tried to move its data from Sybase to Oracle via
> ODBC and almost failed with catastrofic results). 

This is a contrived example on his part.  Oracle and Sybase go out of
their way to introduce minor incompatabilities that make it
difficult/impossible to migrate (usually Oracle-> Sybase in my
experience).  I.e. stored procedure syntax are implemented differently,
views may be constructed differently, the optimizers work differently,
etc.  Problems encountered using an ODBC bridge may expose bugs in a
particular vendor's ODBC suite, but what else can you do?  You sure as
hell can't import an oracle .dmp file into sybase or vice-versa.  Heck, it
could have been the DBA or consultant who set up the copy that nearly
mauled the database.  Allusions to actual events are only FUD w/o details
to support the conclusions you're drawing.

> Wouldn'y it be
> better to use CORBA in this project as well. In this case you would
> have DB objects, one per particular DB. They needn't have the same
> interface, only minimal core services would be standart to guarantee
> minimal functionality. As a result, instead of one interface
> (e.g. ODBC) playing role of common denominator, you will get hierarchy
> of DB objects with simplest posible DB object in the root of it.

The reason to not do this is the following:
1) Gnome shouldn't be in the business of defining a general database
interface standard.  If we want to gurantee certian services, and not
others, then we should use a subset of ODBC's calls and mandate *that* as
supported.  I think this promises to be much easier then trying to write
uniform interfaces to divergent databases, thus ensuring that we're
the only group in the world using this interface.

2) The layered approach is interesting, and worth acting on.  But defining
our own gnome corba bindings for each database on a database-by-database
basis is not the best way to extend gnome.  By using ODBC CORBA bindings
and writing to a ODBC interface we attract commercial software vendors who
would be able to re-use all of their code already written to ODBC, as well
as encouraging free datbases to support CORBA and ODBC.  A good thing in
general!  We also wouldn't have to write and support new modules for
scripting languages like perl which already have ODBC interfaces on every
platform. 

-Peter