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?

b.g.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]


Reply via email to