Re: gda-report and gnue

[Carlos Perello Marin <carlos hispalinux es>]

> > well, I've also been looking at Derek's proposal, and it's really GREAT.
> > And having a report server, as I've understood, is just a CORBA server
> > which will be activated when needed. For small applications, you just
> > have all the components on the same machine, and the user won't notice
> > any difference.
> 
> That is correct.  I havent fully looked into libgda, but figured that is
> how it worked as well.  If necessary we could make it so you could
> encapsulate this w/o CORBA into a small application, but I am not sure I
> see the inherent value.
> 
> Ex: We before have written .dlls that hold the functionality of what
> needs to be done.  This way they can be included directly into an
> application, then a small wrapper was placed around it so it could stand
> on its own as well.  As I said this seems like more work than it its
> worth.  :)
> 
> > And having two kinds of reports (2 implementations) is IMO just a waste
> > of time.
> 
> That was my thought. 
>  

Well, as I have said before, I does not understand the main idea, and
then i propose the 2 implementations, but now i know that you are right
:-)

One library one vote ;-) (Not two)

> > I think we should adopt Derek's ideas. The only thing I don't agree is
> > to have this out of GDA. I think it should go to GDA, for not having to
> > add another dependency out of it.
> 
> This is my reason for not wanting in GDA.  Bloat.  There will be LOTS of
> projects that perhaps want GDA but not reporting why make them have
> both?  By separating it you get that.
> 
> Also and possibly more importantly for GNUe is that while we plan to
> only use libgda at the current time, I think the tool should be able to
> in future allow it to be used with other data access methods if an
> author wants.
> 

Ok, perhaps it could be this way, the only doubt i have is....

> By this I mean WE (GNUe) plans to use libgda, after all it would be dumb
> not too. :)  However a smaller project may want to just connect directly
> to postGRES w/o overhead abstration of libgda.  I think we would have
> more users and a better product if we allowed for this as well.
>



Then, we need to implement an abstract layer to access to the DB?, i
think that it is a waste of time!!!!
I think that we must do to the libgda and if some wants use use other
data source, then HE/SHE must implement this feature into the report
engine (libreport?), it's Free Software :-).


> So I am not proposing we code to anything other than libgda, just like
> no front ends are available for libgda other than Gnome, but I think its
> a good idea to make so there could be. :)
>


I think that we should not do this layer.

> > > P.S.: I think that your model will be perfect. It could include an
> > > Apache plugin for show reports at internet  :-) (like modperl or modphp,
> > > perhaps modgdareport?)
> > >
> > that's a very good idea!
> > 
> 
> This is interesting indeed.  You realize you guys are gonna force me
> into really learning C well if you keep it up. ;-)
>

If all this go well, this will be another argument to migrate
applications to Linux/Unix :-)


Well, then, We could create this library to implement the report engine
(hum... i have think  that we must depend of libgda, because we use the
gda-xml-query, then at the present i think that we should not complicate
all this only to gave it a free DB election.)

Please i need start to codify all this!!!!!, more ideas and, names for
the library?

Bye.
 
> Derek Neighbors
> GNU Enterprise
> http://www.gnue.org
> derek gnue org
> 
> _______________________________________________
> gnome-db-list mailing list
> gnome-db-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-db-list