Re: [gnome-db] New project

["Danilo Schoeneberg (BIMCON)" <extern danilo schoeneberg volkswagen de>]

On Thursday 08 May 2003 13:45, Rodrigo Moya wrote:
> 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!

What kind of events are we talking about? I'm nearly finished with the mSQL
provider, so it might be worth the attempt to build a rough skeleton for the
event notifier.

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

Hm, sounds like an interesting idea, altho some sort of "sub-gda" would
probably save a lot of work, like a meta-provider that "emulates" a DBMS and
just calls plugins that take care of the file-i/o into XML files, CSV files
or some other sort of interchange formats ( STEP anyone? ;) ). I don't know
about the availability, but maybe a little peep into a CSV ODBC driver might
help, i think unixODBC has one, don't shoot me if i'm wrong ;-)

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

hm, you might have a point there, altho i must admit at some points too many
external dependencies might kill the purpose of the excercise. Anybodz that
has ever tried to install GIMP on an IRIX box from tardist archives will know
what i'm talking about - and for those who dont. If you want to install the
GIMP on an Irix box you end up downloading about half a gig of all sorts of
tardist archives just to satisfy all external dependencies and a dependency
on a different language system sound more like somthing that should be taken
on very carefully to me.

> isn't there C APIs for that? (for CSV, since for XML we already have
> libxml2).
>
> cheers

cheers

> _______________________________________________
> gnome-db-list mailing list
> gnome-db-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-db-list

-------------------------------------------------------