Re: [gnome-db] New project

["C.J. Collier" <cjcollier colliertech org>]

> > Is this how doc/C/mergeant.sgml was generated?
> > 
> mergeant's setup is a bit different, since it's got no API docs. So, we
> just use docbook's tools (db2html, db2ps...) to convert the docbook
> documentation into different formats.

How'd you get the docbook documentation in the first place?

> > I want to use references, but rather than using pointers, I'd like to
> > use some sort of hyperlink to a data set in a database.
> > 
> hmm, if you're using GTK widgets, using normal drag and drop could give
> you this. That is, when some data dragged from your app is dropped into
> another app, you get, in your app, a request for the data, which you
> could provide as requested by the "client" app.

I thought that might be a way to go about it.  Does libgda cache the
data in memory?  It'd be more efficient than making queries to the data
source from each application.  I wouldn't want wait 2ms for each request
I make from my 3d apps, especially if I'm doing rotation and streching
and realtime stuff like that.  Perhaps shared memory is a good way to go
about this?  I don't know much about this stuff...

> > Wonderful!  I'm not too busy to get my hands dirty.  I've always enjoyed
> > writing glib code.  As I get more comfortable, I'll jump in and start
> > hacking a bit on libgda.
> > 
> cool!

Can you tell me where to start if I want to learn the libgda api and see
some simple, practical examples?

> > Does this mean that libgda might have to write some provider-specific
> > code?
> >
> no, if we can avoid it. Provider-specific code should be in the
> providers, not in the library.

Hear hear.  Would building a provider for CSV would be a good start,
then?  It may teach me a bit about data mangling and providing a clean
API.

> >   What if I were to write a wrapper DBMS engine that handled SQL
> > queries around data sources like CSV and XML files: things that don't
> > have native DBMSs.
> >
> you can do it, as we've got, not fully completed, a LDAP provider, a
> XML-based provider, etc

Right-o.  Anything I should read first?


> >   If we decided to go in this direction, it
> > might be worth noting the existance of the Perl plaintext DBD libraries
> > which already, to some extent, provide this functionality.  This means
> > that if we don't mind using libperl, we don't have to start this from
> > scratch.  There already exists a DBD::CSV, and there has been quite a
> > bit of discussion about DBD::XML.
> > 
> isn't there C APIs for that? (for CSV, since for XML we already have
> libxml2).

There may very well be.  I'd have to look into that, I s'pose.

> cheers

Yay!  Cheers!

C.J.