Re: ODBC Driver Manager Questions

[Murray Todd Williams <murray verinet com>]

> > Personally, I'd like to work on contributing toward making Gnome-DB work
> > with either unixODBC or iODBC.  (The library API's are almost exactly
> > alike.  It used to be that unixODBC had the added functions of ODBC ver.
> > 3, but even that should be parallel by now.)  I would like to also add
> > the Driver Manager ODBC Administration GUI components to unixODBC.
> >
> > In fact, it strikes me as a little disconcerting that Gnome-DB has iODBC
> > as an installing component.  I haven't tried yet, but can one install
> > Gnome-DB without the iODBC part being built and installed over whatever
> > pre-existing ODBC Driver Manager there might be?  That could be damaging
> > to someone with a pre-existing ODBC system configured.  If anything, I
> > would think the iODBC stuff should be made optional.  Presently, I know
> > that the MyODBC source's configure options include --with-iodbc for
> > iODBC and --with-odbc for unixODBC.
> >
> > Anyway, I know my interests lie much more with pre ODBC than with the
> > comprehensive scope of Gnome-DB, but I'd like to make some contributions
> > to unixODBC and Gnome, and I'd like for those contributions to be easily
> > integrated with Gnome-DB.
>
> That's one of the things that needed to be changed, specially since Daniel
> Horak (who is making the spec files for GNOME-DB) found conflict problems
> with the ODBC RPMs. What do you think about still providing a default
> ODBC implementation (along with the postgres ODBC driver) in case none is
> installed? or should we do as with the other servers (no client libs, no
> GDA provider)?

That's a tough question.  The background of the iODBC Driver Manager is rather
complicated.  The code was pretty old and people were batting around half a
dozen versions that had various patchwork fixes.  Of course, once OpenLink
took over management, the code solidified, but there are quite a few versions
out there.  Hopefully with time that will diminish.

There are three problems with providing a default ODBC Driver Manager along
with Gnome-DB.  First of all, there's the question of which major
implementation to use: unixODBC or iODBC.  Both are valid Driver Managers and
both work with all Linux OBDC drivers (known to me).  The second problem is
the fact that the code base for at least unixODBC is rather large.  Not huge,
but I don't know if people building Gnome-DB for the first time want to
dedicate all that much build time to a non-Gnome-DB component.  The third
problem is keeping current with the development of the driver manager.  I
can't speak for iODBC (maintained mostly by OpenLink), but Nick
Gorham--current maintainer of unixODBC--has been working really hard over the
last year to make unixODBC really really good.

Given those three problems, it might be best to keep pointers to RPM's and
tarballs for unixODBC and iODBC.

Personally, I think that there could be a good synergism between the unixODBC
and Gnome projects.  unixODBC has a very nice feature that iODBC does not.  In
addition to supporting the standard ODBC ver 3.5 API, there is also a standard
API for the installation and management of ODBC Drivers.  This API is used by
Microsoft in their products to assist other 3rd party companies to easily
install new drivers into the operating system.  unixODBC provides this API
both in terms of a shared library (and header files) *AND* as a command-line
utility that can be easily invoked with an RPM script, thus allowing RPM'd
packages to smoothly "drop in" new drivers.  Once again, this is completely
compatible with the Microsoft spec.  (Remember, MS actually worked along with
the other companies to establish the ODBC standard.  Believe it or not.)

Another thing that unixODBC provides is a KDE utility that mirrors (and
resembles) the Microsoft ODBC Driver Administrator program.  It's just a
simple GUI program that uses the odbcinst libraries to do driver and
datasource management.  The thing I was just getting involved in was writing a
Gnome-based equivalent.  Eventually the three would (unixODBC, KDE front-end
and GNOME front-end) would be packaged in separate RPM's.  That way if you had
KDE and/or GNOME, you could install the front-end of your choice and still
have the same fundamental ODBC Driver Manager running at the core.

I would like (if there are no objections) to see if Gnome-DB and unixODBC
would be interested in working in conjunction so that they fit together
seamlessly.  I would write the Gnome-based OBDC Driver Administrator controls
and help determine how it can best fit in with Gnome-DB.

> Apart from adapting the source files/Makefiles to the different ODBC
> implementations, I was thinking on rewriting the ODBC provider, which was
> the first one to be added, and is completely messed. If you want to do
> this, you can use the template files (in gda-dev/templates) to start and
> then fill in the gaps, although these templates have been only partially
> tested. But it shouldn't be too hard. If you do this, remember to contact
> me before you start with the schema implementations, since there is missing
> code in the template files about this. I don't recommend you to just patch
> the current sources, it can be a nightmare.

I think at the moment I'll pass on that piece.  I'm really trying to make sure
I don't bite off more I can chew with the Gnome ODBC Driver Administrator
piece.  I don't have the bandwidth at the moment to learn the inner-workings
of Gnome-DB.  (Mostly I'm terrified whenever someone mentions CORBA because I
get the impression it's really complicated.)

> If you want to help on the ODBC manager GUI, you can also help us. Stephan
> Heinze (<stephan.heinze@xcom.de>) was thinking something about the GNOME-DB
> administration tool. What I think mysef is that we provide a shared library
> for each provider containing the implementation of a widget which is to be
> displayed in the gda-mgr tool. Having a widget interface would allow you to
> make an ODBC-only admin tool to contribute to the ODBC project as you said
> by just inserting this widget in another app. The widget for each provider
> will display all the available options for the underlying database, as the
> ODBC manager applet on Windows do.

If I understand you correctly, that's already implimented in unixODBC in a
way.  All known ODBC Drivers have equivalent shared libs that help describe
(sort of an intraspection thing) the various parameters that the driver needs
to establish a connection.  There are also two shared libs for fairly
"generic" cases where a custom-designed lib doesn't exist.  Finally (I believe
I'm right with this) if an ODBC driver is really well-written, it'll tell the
Driver Manager *itself* what parameters it needs.

I'd be happy to try and help write a similar "widget" for the ODBC provider.
In that case I really suggest Gnome-DB chooses unixODBC for a Driver Manager
because of the driver management and data-source management libraries that I
described earlier.  Plus, Nick Gorham (again, the unixODBC person) is really
really responsive about making changes and alterations and fixes with
unixODBC.  If you choose iODBC instead you'll be reinventing the wheel.  (And
taking time away from the more Gnome-DB-centric work that I suspect you are
all interested in doing.)

> > Also, I noticed on an earlier e-mail that someone was talking about
> > setting up RPMs.  I just got my copy of "Maximum RPM" and have created
> > RPMs for a couple packages (unixODBC, freeodbc++ and MyODBC) and would
> > be willing to get involved in the RPM preparation.
>
> Get in contact with Daniel Horak. He is right now making the spec file for
> the core, that is, the client libs and apps. Then, there will be a RPM for
> each provider. The ODBC provider RPM should know whether iODBC or unixodbc
> are installed, as the others.

What might be fair would be to let Nick and me work on a full-featured
unixODBC provider component (along with the widget goodies, etc.) and make an
iODBC provider that would assume iODBC was already installed (to be fair for
people with pre-existing iODBC installations) that would skip the driver
administration components, simply allow you to choose a datasource, and let
the burden of datasource configuration rest with the user.  The unixODBC RPM
and iODBC RPM could simply keep a "conflict" note in the spec file so both
were installed on the system.  Is any of this making sense?

> Cheers

Cheers!  Back at ya!

Murray Todd Williams