Re: [gnome-db] Re: post-GUADEC plans

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2003-06-23 at 10:34, Vivien Malerba STNA 7FD M204 wrote:
> 
> > 
> > * unfortunately, I don't think Mergeant is ready for 1.0 yet, so all
> > this would mean that we would decouple libgda/libgnomedb and mergeant to
> > be separated releases. A worst consequence of this could be that
> > Mergeant is not included in the GNOME Office release. Or do you think
> > with a bit of bugfixing mergeant, with its current features, can be
> > released as a 1.0 software?
> 
> Right, Mergeant is not yet ready for 1.0 release (it still has many
> crashes, it can't do a lot of things, etc). In fact I'm planning a
> complete rewrite of it using a new library I'm currently writing (which
> I've, suprisingly, named libmergeant).
> 
oh, how far are you on that rewrite? Having a library would be really
good to provide, apart from mergeant, components that operate, within
nautilus, with mergeant files.

> I plan to make a bit more work on that lib and release it soon.
> Basically the new lib will have the following features:
> - uses libgda for any access to the DBMS
>
cool. I find the layers in mergeant a bit redundant. So letting libgda
do the job will reduce a lot of code and a lot of crashes.

> - creates a memory structure for all the DBMS objects (data types,
> functions, aggregates, tables, views, tables fields, some constraints so
> far)
>
can't this be done using data models instead of having another in-memory
structure? Think that the data models keep the data also in memory, so
it might be redundant.

Also, using data models directly will allow mergeant to be notified
(once we implement it) when the data model changes.

> - creates memory structures for any type of DML query (even complex ones
> with sub-queries) and can render them to SQL (and hopefully to XQL
> later).
>
cool

> - each query can have execution parameters which must (or may) be
> provided before query execution
>
also cool

> - has a powerfull widget to display and select most of the types of
> objects in libmergeant (table, fields, data types, queries, etc)
> - has several widgets to make it easy to have a form and a tabular views
> of data
>
I think we could have this in GnomeDbForm, in libgnomedb. If we let the
data management to libgda/libgnomedb, that should be possible. Or are
you thinking on other features only available in mergeant?

> - has a plugin system to extend the default widgets used to enter or
> modify data, depending on the data type of the manipulated data.
>
also something that could be in libgnomedb.

> - uses XML for all the storage issues.
> - can optionnaly use libgnomedb for some better features.
>
why optionally? I would vote for putting all generic features in
libgnomedb.

> - has an up-to-date (well almost) documentation using gtk-doc

> I plan then to extend it to have more graphical components (like a
> specialized canvas), DDL queries and reports generation.
> 
again, the reports UI should be in libgnomedb, based on the
libgda-report we've got in libgda. Mergeant, IMO, should just provide a
good frontend for all that, that is, use them in a coherent UI.

> When that lib is ready, a rewrite of mergeant using the lib will not be
> very difficult as most of the features currently provided by mergeant
> will be in libmergeant. Libmergeant can of course be used outside the
> scope of mergeant itself.
> 
> Maybe, if you find the library usefull and if the lib is stable enough
> (which I think will be the case), we can then make common releases of
> libgda/libgnomedb/libmergeant/mergeant, no?
> 
yes, of course. The only reason to separate the releases right now would
be to release libgda/libgnomedb 1.0. We can still do coordinated
releases, even if the version numbers don't match.

I would though, for the time being, distribute libmergeant as part of
mergeant, not as a separate package.

cheers