Re: [gnome-db] more refactoring



On Mon, 2002-04-22 at 08:39, Jean-Michel POURE wrote:
> Le Dimanche 21 Avril 2002 02:57, Rodrigo Moya a écrit :
> > So, how does this sound? Any concern/suggestion/opinion?
> 
> Hello,
> 
> I contribute to a project called pgAdmin2, PostgreSQL Windows GUI, which I 
> would like to port to Gnome or KDE. I am looking for a good database 
> abstraction layer with multiple providers.
> 
libgda with this change I'm about to commit in these days (yes, it's
almost finished :-) would be a perfect choice, since it's got few
dependencies, and is a tiny library, which wraps perfectly many DBMS'

> Libgda is a great project. Here are my questions:
> 
> 1) C++
> Looking at the code, the authors seemed to write C++ using C. In my humble 
> opinion, data providers could gain from a class abstraction and inheritance.
> 
we use the GObject system, which is a system in GLib which allows OOP in
C. It is used everywhere in GNOME.
We use, for data providers, class abstraction and inheritance:
GdaServerProvider is an abstract class, and GdaPostgresProvider,
GdaMysqlProvider, etc, are just child classes of it.

> Is there any reasons why C++ (or Python) were not used? Using C++ would reduce 
> the work needed for writting new providers ... and these providers would be 
> more powerfull.
> 
yes, there are many reasons:
* C is the prefered language in GNOME
* we prefer C
* the OO support in GObject is all what we need
* we don't like C++ (at least I don't)
* python is not good for low-level programming, for performance reasons
specially
* and, last but not least, we are going to provide bindings for many
languages, so you would be able to use libgda from the language you
prefer. For the GNOME 1 version, you've got 100% functional C++
bindings.

> 2) XML
> Also, I would like to know if you consider using more XML for data provider 
> description. Many features are presently hard-coded in C. Embeeded XML in C++ 
> would be great to describe specific features of each provider.
> 
we are using XML for many things, so it makes sense to use it for
everything that sounds good. So, what are your ideas exactly?

> 3) Examples
> For example, PostgreSQL provides several server-side languages (PLpython, 
> PLperl, PLpgSQL, etc...), multi-byte data and client-side recoding, triggers. 
> Are these specific features described in libgda? 
> 
some of them yes. The ones that are not supported yet, will be
supported. The plan is to have libgda replace the most full-featured DB
API out there, so everything should be doable in libgda.

> By now, my opinion is that I should start a Python database abstraction layer. 
> Before doing so, I would like to learn more about libgda future directions.
> 
as you now know, we are going to have it be just a tiny library, with
loadable plugins for each of the supported DBMS.
The API, as I said, contains a lot of things, and anything that you (or
somebody else) finds missing, will be added, if it makes sense, of
course.
We just need a person to make the initial work of the bindings (most of
which is already done in the gnomemm project), and thus have almost
automatically bindings for Perl, Python, C++, guile, etc.
Then, we always welcome new data providers, since we want to support
*all* DBMS

> Are you going to provide a better object-oriented structure (C++) with XML for 
> libgda? What is your personal opinion?
> 
the API is fully-object-oriented. What are the exact things you find
missing or that need changes?

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]