Re: [gnome-db]'i'd like to colaborate adding more providers'

[Rodrigo Moya <rodrigo gnome-db org>]

Hi Steve!

> I chose the best fit option here, but my message is not an exact fit.
>
yes, that page must be updated. (BTW, Jorge, it would be a great thing
to have at that page links to some bugzilla queries. If you want to do
it, just tell me and I'll send you some queries I've got)

> I'm working with a team of MS Access refugees (see 
> sourceforge.net/projects/ddpi) to achieve an approximate functional 
> replacement for MS Access 97.  We don't necessarily care if we do this
by 
> making something basically new or by putting our efforts into an
existing 
> project moving in approximately the same direction, but with a focus
on 
> implementing the specific features and capabilities we want to have.
>
I think we're in the same boat, since the goal of gnome-db (not libgda,
just gnome-db) is to be something similar to Access. By this I mean,
that we want it to have at least the same features as MS Access, but
also adding new features that MS Access does not have.

The problem is that most development time has gone to libgda and to
implement just the basic features in gnome-db, so lots of things are
missing on gnome-db to reach the feature list of MS Access. But work is
on the way for all of them (see below).

> I'm sending this message to you because we may or may not want to join
the 
> GNOME-DB project, and we may or may not want to adopt libgda even if
we 
> don't, but the on-line documentation is insufficient to answer the 
> questions we have about libgda.  If it's not too much trouble, I'd
like to 
> have you read the following list of our goals (as I, personally see
them) 
> to see if they seem to be compatible with the goals of GNOME-DB, and
my 
> questions about libgda and see if you can give me a clearer picture.
>
> Thanks in advance.
>
> Our goals:
> 1.  A database front end and interactive RAD environment.
yes, the same as gnome-db. The database front end is what exists right
now (with some missing stuff), and the RAD environment is planned, as
soon as there's some work put on Glade to export its functionality via
Bonobo components.

> 2.  Must be fully functional on at least the Linux and MS Windows
platforms 
> (MS Windows is imperative).
we have not planned to target the MS windows platform, but due to the
clean separation of all modules in libgda, it is perfectly possible to
make a port to Windows. I'm not so sure though about the amount of code
that could be shared for the UI part (gnome-db), since it is very
GNOME-specific. But as I said, it would be quite easy to write a Windows
frontend for libgda after making the port of the basic parts of libgda.

> 3.  Powerful reporting on reasonable parity with MS Access (so far,
nothing 
> else comes close).
yes, Carlos and I are (slowly) working on a CORBA-based report engine,
which is part of libgda, and for which there will be some UI tools based
on it: a report designer and a report viewer. Currently, nothing of this
is working, but you can see the first code snapshots on CVS (under
libgda/report/)

> 4.  Allows SQL queries of both ODBC data and at least one kind of
shared 
> file data (could be through ODBC driver).
>
yes, SQL queries to ODBC data is already supported, through the use of
the ODBC provider. About shared file data, it's planned to make, now
that we've got the XML queries stuff available, some providers to access
this kind of data sources (XML, comma-separated-values).

> libgda questions (not really worded as questions, but you get the
idea):
> >From the documentation, I cannot tell if it is possible to do SQL
queries 
> of data sources that support SQL (such as ODBC, PostgreSQL, etc.).  I
see 
> you are working on a unified XML query system for all data sources,
but I 
> hope this is taking into account that queries should translated, to
the 
> greatest degree possible, to back-end queries for optimal speed.  Our
group 
yes, XML queries are an OPTIONAL way of sending commands to providers.
SQL (or whatever language the DB server uses) is the default way. In
fact, there are functions in the libgda API to discover all this at
execution time:

if (gda_connection_supports(cnc, GDA_Connection_FEATURE_SQL))
    ---> execute SQL query
else ---> execute XML query

so that you can send SQL better than XML if the underlying DB system
allows it.

> would benefit greatly from a unified SQL query system as well, but I
think 
> we could live with handling that by using ODBC even if that means
using 
> ODBC where a specific libgda driver would be more efficient.  Would it
be 
> consistent with GNOME-DB philosophy to add a unified SQL query system
in 
> parallel with the XML system?
yes, we've talked some times about this, but haven't arrived to a
solution yet, specially after we decided to go with the XML queries for
cross-db commands. I suppose you mean to have a sort of SQL parser which
converts a standard SQL to the specific SQL of the provider it's
connected to? or what do you mean by unified SQL query system?

cheers


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