Re: gnome-db/TOAD/gASQL (was Re: [gnome-db]Access-like prkect)

[Rodrigo Moya <rodrigo gnome-db org>]

On 27 Jul 2001 18:02:47 +0200, Philippe Roy wrote:
> Hi, 
> 
> 
> > > > I remember talking with you (I think) about you using libgda. Did you
> > > > find problems/limitations in libgda for not using it? if so, please
> > tell
> > > > me which ones
> > > 
> > > The major reason is "I don't want a CORBA requirement, optional only".
> > > I don't understand the problem solved by CORBA for an open source
> > platform.
> > > Building components ? I think there are better way: shared lib,
> > plug-in,
> > > guile, command line, pipe, (soup ?), ... .
> > > 
> > > I'm sorry, I don't have a great experience with corba apps (panel,
> > control
> > > panel, ...).
> > > They are big, slow, unstable, with overcomplicated code and with a
> > > nightmarish installation.
> > > I don't want imagine this in intensive production context. I think
> > there
> > > are others solutions.
> > 
> > 
> > Well, then. wouldn't you port your application to GNOME 2.0?. It's 100%
> > CORBA based because the use of Bonobo :-?
> 
> Is GIMP include in GNOME 2.0 ?
> I didn't say "never", I'm not enthusiastic only (like lot of users).
> Perhaps a bridge between guile and bonobo ?
> 
there is already one. But, this would be much slower than just using
plain C, so this won't be the solution for your speed problems (I say
"your" since I don't experience  speed problems on the panel or the
control center. I do on some apps that make heavy use of Bonobo, but
nothing that is not fixable, and nothing too noticeable compared to
other non-CORBA apps)

And why are you not enthusiastic? It seems CORBA makes it easier for
programmers and users to reuse what's available, apart from being ready
for distributed apps, which is something more and more popular in these
days.

I mean, to make a simple calculator, maybe CORBA is not the best choice,
but for office-like apps, it seems to me the best way to be able to
share features,etc with other apps. For example, it would be really
interesting if Abiword or gnumeric could embed the output from our
reports, or similar things.

> 
> > > About the report system, I'm inspirated by glade, by framemaker and
> > > presentation software.
> > > I think a GUI for building xsl file or LaTeX class is the solution for
> > all
> > > publication problem (paper/web, listing/presentation, ...).
> > > 
> > 
> > 
> > We will build the report interface with something like glade (or perhaps
> > directly with glade, I don't know) and the output will be a xml file
> > that will use our DTD (it's at libgda/report). This xml will be
> > translated into .ps, .pdf,.html and perhaps into LaTeX (all this filters
> > will be plugins, so you could create all the outputs you want).
> 
> 
> Pdf and Postscript aren't human readable. HTML isn't a printing format.
> I don't understand why the GNOME platforme ignore the better printing
> system called LaTeX, very strange ?
>
I don't think it's being ignored, but AFAIK, there are other formats
that are becoming more popular (not to say better than LaTeX, but more
popular)
 
> A report system have 2 parts : extracting and formating.
> Are they independants ?
> 
yes, the report engine will only know how to write our XML DTD. Then
there will be support (via XSLT or via plugins, we're not sure yet) to
convert this to different formats. But this will be something to be done
on the client side, not on the report engine

> xslt seems good for the xml transformation : xml->xml, xml->html,
> xml->sgml, xml->latex, xml->txt, xml->csv, xml->svg, xml->... .
> Why we need plug-ins ?
> The ps is generated with latex after the 'xml->latex' xlst operation.
>
that's why we're thinking on some sort of plugin system, we're not sure
yet, since we want first to have the basic framework working, and then
we'll see what to do, although I think best way is via XSLT.
 
> The main task of the formating system is only create the xls file.
> Perharps the associated file format of the report system is the xls file.
> Why not ?
> 
> In the latex case, the formating system can create the class file too.
> In the html case, the formating system can create the css file too.
> 
that's why maybe a mix between XSLT and a plugin system might be interesting,
since, as you say, there are different steps to be done for each format,
so this could be easily done in plugins that use libxslt

cheers
-- 
Rodrigo Moya <rodrigo gnome-db org> - <rodrigo ximian com>
http://www.gnome-db.org/ - http://www.ximian.com/