Re: [gnome-db] New project

[Rodrigo Moya <rodrigo gnome-db org>]

On Thu, 2003-05-08 at 00:29, C.J. Collier wrote:
> > > 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?
> 
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.

> > > 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.
> 
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'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.
> 
cool!

> > 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?
>
no, if we can avoid it. Provider-specific code should be in the
providers, not in the library.

>   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

>   It would be a bit of a job, but it might be worth
> the effort in the future.
>
it is a bit of a job to simulate the things that are not supported. But,
it's worth the effort, yes

>   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).

cheers