There has been some discussion recently over whether the engine should
have features that allow extracting higher-level summary information
(such as totals etc.) for reporting purposes.
In the medium to long term, it would be great to move gnucash to support
multiple users, with the engine backend sitting on a server and the
client(s) communicating with the server (possibly using CORBA or some
similar method). We may even have multiple implementations of the
engine, some of which may support different methods of extracting
report-relevant data - and, for that matter, multiple implmentations
of the client - who knows, we might even have implementations of both
client and server which are by third parties.
Therefore, discussions of what's appropriate to go into the engine and
what should go into the UI should be taken in that context.
Looking at the kind of reports that are likely to be needed (a full
discussion of required reports will be in a subsequent mail), they can be broadly
categorised as transaction reports, total reports (where balances at a
point or changes in balances over an interval are summarised), and
investment reports, where various non-trivial calculations are
performed on the splits in an account or multiple accounts (such as
calculating cost basis and ROI).
Transaction reports may involve large numbers of transactions, but all
that needs to be done is to extract the relevant splits and send them
to the UI for rendering. Once we have the query interface wrapped, to allow
the efficient extraction of relevant splits from the engine, that's
about as efficient as we're likely to get. Shifting any more
computation into the server is just placing more processor and memory
load on that server, makes modifying the reports more difficult (it's
much easier for users to customise the rendering of their reports if
the rendering is done at the client end), and makes the server bigger,
uglier, and less maintainable.
As stated previously, investment reports (I'm generalising here)
require some rather non-trivial calculations that vary from report to
report and undoubtedly from country to country.
The good news with investment reports, however, is that they are
unlikely to involve hundreds of thousands of transactions. Typically,
they will be used by home and small business users, and involve
hundreds, thousands, or at the very outside tens of thousands of
transactions - the sort of thing that comfortably sits inside the main
memory of a modern machine. Therefore, it's not going to overload the
server, or overload the network, if we send those transactions to the
client to process - again, provided the query interface allows us to
efficiently extract the relevant transactions. Doing the complex
calculations in the client also keeps that complexity out of the
engine, which is again a good thing.
However, "total reports" could be done rather more efficiently if,
instead of sending all the splits to the client for calculating
totals, those totals were calculated by the engine. This would
require very little engine code, greatly reduce network traffic,
would allow "optimized" methods that
a database-backend engine could use, would cause very little extra
work for the engine (in fact, the reduction in network traffic might
give us a net reduction in processor load), and simplify the client
reporting code.
So, in essence, I would argue for a small extension to the query
interface to allow totals rather than split lists to be returned,
wrapped, like the rest of the query engine, for use by the Scheme
reporting code. Anything more complex than totals,
etc. etc. should be kept away from the engine - if it turned out that
similar calculations were being used in multiple reports we should
generalise them on the client side and keep them out of the engine.
Comments?
------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
------------------------------------------------------------
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
