Re: ODBC Driver Manager Questions
- From: Rodrigo Moya <rmoya tsai es>
- To: gnome-db-list gnome org
- Subject: Re: ODBC Driver Manager Questions
- Date: Mon, 17 Jan 2000 16:09:51 +0100
>
> > 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.
I meant to still include the current version of iODBC that comes actually with
gnome-db, and modify the Makefiles etc to detect which version of ODBC is
installed, and if none is installed, use the default one. The other possibility
is to do as with the other servers, there are no client libraries, the
ODBC provider is not built. iODBC was used, because it was the only ODBC
implementation present at the moment.
>
>
> 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.
>
Yes, that's what I thought, specially since, as I've seen, people tend to use the
PostgreSQL/oracle/MySQL providers instead of the ODBC one. But it was provided so
that people without a database on their systems could run gnome-db.
>
> 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.
>
No objections at all from my part. I think the best way is to do what I said in
my previous message: to have a widget implementing all the configuration, so that
in the gnome-odbc manager, or gnome-db's gda-mgr just have to act as containers
for these widgets.
>
> > 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.)
>
Ok, the driver manager looks very good to me. But I must say that all the
template files I'm talking about are there to hide all the CORBA stuff, so it
shouldn't be too hard.
>
> > 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.)
>
As you said, iODBC does not provide the ODBC setup libs, right? so we'll build
this component in gnome-db only if unixODBC is present on the system. The ODBC
provider could still be built with both.
> 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?
>
Do you think it's a good solution to provide 2 gnome-db ODBC providers (1 for
iODBC another for unixODBC), instead of making only one (with #ifdef's for any
psossible difference in code)? If so, go on, but remember to use the templates
in gda-dev/templates.
A question: where can I download unixODBC?
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]