Re: [gnome-db] New project

[Rodrigo Moya <rodrigo gnome-db org>]

On Thu, 2003-05-08 at 17:01, C.J. Collier wrote:
> > > 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?
> 
writing it directly in DocBook format, in doc/C/mergeant.sgml.

> > > 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?
>
as long as the data model is not destroyed, the data is in memory. Or
are you talking about keeping it in a cache, regardless of whether the
data model has been destroyed or not?

>   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...
> 
hmm, passing all the data model via drag & drop might be quicker, or
slower, not sure. You could pass it in XML format, or just pass a
reference in the form of a Bonobo moniker, to be activated from the app
where the data is dropped. Then, in the dragged app, you can just return
the data model when asked for the moniker.

> > > 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?
> 
well, to learn the API, look at the sources themselves, they're the best
"documentation". As a simple example, we've got gda-test, in
libgda/testing. It's not that simple, since it's an API test program,
but might give you a good vision of how the API is used.

> > > 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.
> 
yes, it might be a good start. It's planned indeed, so if you want to
work on it, go ahead. Only one thing to have in mind is having a
libgda-generic provider, as was suggested, that implements all the
common stuff, only leaving the file I/O part to the real provider.

> > >   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?
> 
the source code :-) Also, German (CC'ed) can give you some help on the
LDAP provider, since he wrote it.

cheers