Bill Gribble writes:
> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > Personally, I think that this is one weakness in the present approach to
> > report generation. I would prefer to see an implementation that does the
> > calculations in the engine (as directed by the report generator) and only
> > does the displaying in the external part.
>
> This is being planned. We have the same concerns; currently there are
> a few places in the code where things like reports are generated by
> iterating over all the splits. That functionality should be set up so
> that a different backend could help performance if the underlying data
> abstraction supports some operations directly. Of course there will
> be computations that aren't in the engine, but if you have a good set
> in there you can reduce the problem significantly.
>
> Finishing the process of publishing the Query API to scheme is a
> start. After that, we need to start specifying what kind of
> processing primitives the engine should have. Any thoughts?
I've just been thinking about this quite a bit (in between rebuilding
my gnome setup after trying to add various CVS bits and having to
remove them again . . .).
I'll post a summary of this and other issues tomorrow morning.
------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
------------------------------------------------------------
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
