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

[Rodrigo Moya <rodrigo gnome-db org>]

> 
> > 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.
> 
> Sounds like something we might want to help expidite then.
> 
> > 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.
> 
> A successful port of GNOME was recently accomplished via U/WIN (though 
> undistributable due to licensing).  Do you think the same could be 
> accomplished in the near future with Cygwin to get something nominally 
> working, then port parts to native Windows API incrementally?
> 

yes, in fact, all the GTK part could be compiled with no problem on
Windows, using the GTK port, but what won't be so easy is the Bonobo
stuff. For this, you would need a Bonobo port to Windows, which will
only be possible (for the moment) with U/Win and this kind of software.

That's why I think that a specific Windows version should be implemented
separately, to take advantage of the component architecture of gnome-db,
and do the same for the MS world. Of course, a simple GTK application
could be done, reusing lots of code from the current gnome-db source
code, without any component stuff.

> > 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/)
> 
> As soon as I get around to figuring out CVS (we've only been here a week or 
> 2).
> 

you can get CVS snapshots (which are built every night) at
http://www.gnome-db.org/download if you have problems getting the code
from CVS.

> > 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).
> 
> Now I just have to find a portable GPL-compatable ODBC driver.  LocalSQL is 

unixODBC (http://www.unixodbc.org) is GPL-compatible AFAIK.

> the closest thing I've found, but it's heavily Qt.  I'm checking now to see 
> if it will be possible to use the Windows X version without the Graphical 
> functionality and run it on Windows without X.
> 
> > 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:
> 
> That was actually 2 questions, and you answered the critical one.  My 
> lesser question was whether you would try to have your XML query engine try 
> to delegate work to the back-end for best performance.  I ask this because 
> that's what Jet does with local SQL queries against linked tables.  If, for 
> instance, you perform a join of 2 tables from the same back-end, jet is 
> smart enough to have the server perform the join instead of dragging all 
> the rows through the client.  In this way, it is often possible to get 
> comparable performance with the unified system as you would get with a 
> native query.
> 

yes, definitely this is a good thing to have. And the base stuff is
already available to implement this, since we can hook many things both
in the client and provider parts, since there is, for both parts, a
shared wrapper. This is specially useful in the provider parts, where
there are many providers:  we could hook this functionality in the
libgdaserver library

> 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?
> 
> Well, I mean that you seem to have opted for an XML query engine as a 
> unified way of querying from any back-end rather than an SQL engine.  I was 
> meaning to say what if you were to have both that and an SQL engine as 
> unified engines and be able to choose either.  That wouldn't be a necessary 
> feature for our priorities (especially since using ODBC everywhere has a 
> similar effect), but a nice thing when you want to make it easy to migrate 
> from MS Access.
> 

yes, also a good idea.

> One other thing I was curious about.  libgda looks (FWICT) pretty 
> isomorphic with 2-dimensional tables, but you want to support data sources 
> that don't resemble that, so the drivers will have to do some 
> force-fitting.  Now you're adding a unified XML query engine, so, if you 
> were querying an XML back-end ... well, I think you see where I'm going. 
>  Why wasn't libgda more isomorphic with DOM or SAX which still would have 
> been pretty easy to fit 2-dimensional data types into, but would have been 
> more flexible for other types of data?
> 
yes, you're right. I've sometimes thought about this, specially when thinking about

the XML provider, which should be able to map any xml file, not only one
representing a 2-dimensional table-based database.
what ideas have you got on this issue?

cheers

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