Re: [gnome-db] New project

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

> > What do you guys use to generate your
> > SGML documentation?  Right now, I'm using xemacs ;)
> > 
> we use gtk-doc, which is the standard for API documentation in GNOME. We
> have a main sgml file and comments on the source code for each function.
> gtk-doc then creates docbook files from the comments.

Is this how doc/C/mergeant.sgml was generated?

> > I want to allow drag and drop events between my applications, but
> > instead of dragging and dropping entire data structures, I just want to
> > dnd database information.  So I'd like to drag a model from one tool to
> > another and have the applications pull the information from the
> > database.
> > 
> I don't understand what you mean. Do you want to pass the full model or
> just a reference to the data to be read?

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.

> > I'd like to do this to minimize duplication of data.  So, of course,
> > updates to the database must be propogated to any applications that are
> > viewing the table.  Is there a way to emit signals to applications that
> > are using the gnome-db tools on update/insert?
> > 
> there is a way in the API, although it's unimplemented in the providers
> so far. This is the gda_client_notify_event function, to be called by
> providers for all events we want to signal from the DB to the clients.

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.

> For this, we just need to extend the GdaClientEvent enum to include all
> the events we want, and have the providers listen for changes and signal
> clients about them. For instance, in Postgres we have the NOTIFY command
> IIRC. Other providers should use whatever mechanism they have available.

Right-o.

> The only problem with this is what to do with providers that can't get
> those notifications. Having apps relying on them but using providers
> that don't support them might be a very bad thing.

Does this mean that libgda might have to write some provider-specific
code?  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.  It would be a bit of a job, but it might be worth
the effort in the future.  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.

> cheers

Right back atcha.

C.J.