Reporting system and potentially Python

[Tim M]

Yawar's suggestion is quite interesting, but the declarative XML you suggest
is bordering the functionality of a web service.  I like the idea of having
the XML declarations but there still then must be some way for the user to
select individual accounts included in the report, which will require some
communication between the reporting system and gnucash.

I think a web service would actually be perfect for this, as this would then
totally externalize the reporting infrastructure.  I'm not sure, however,
exactly what implications this would have.  I would have to see how this can
be handled - if a port can simply be opened and listened on for requests, or
if it would require bundling some type of web service such as tomcat.  I
would think it could be done just using a listening port but I haven't
actually written a web service before so I'm not sure.  There are probably
libraries already available which could handle the requests, otherwise we
would have to roll our own.  Also, I wonder if we can make the actual
requests with Javascript - the WSDL would eliminate the C -> Javascript
access issues mentioned earlier.


What this would require then would be to create a WSDL for the available
methods and then similar to Yawar's suggestion, the report would make a
request to the GnuCash web service for the information needed to generate
the report, and the web service would return the results as XML.  At that
point the XSLT would transform the XML data into HTML for display and voila,
you have a report which has been generated entirely using code and methods
externally accessible from GnuCash.


Having a web service could make for some very interesting use cases such as
generating reports directly inside a web page (such as if a business has an
intranet where they want to be able to gather and view their financial
data).  Also, it opens up the possibility of creating additional web service
methods which not only read but also write data.  For example, a user could
enter transactions from a web form and on submitting the form, the web
service request is sent to GnuCash which adds the txn to the database for
the appropriate account.

Another use case for a read/write web service would be having a "GnuCash
Server" which would mitigate the problems associated with having multiple
clients reading and writing to gnucash at one time.  For example, GnuCash
would sit on a dedicated system listening for web service requests.  Client
machines running copies of GnuCash would then connect to the server (I think
it could be implemented as just another interface to the data such as we
have XML and DBI currently) to access the GnuCash data.  Finally, when a
user action causes a insert/update/delete request, all user's requests would
go through the central GnuCash server so they would not be able to access
the file concurrently, thus preventing user collisions when editing the
file.  This is of course very ambitious and wouldn't happen unless someone
saw the need and implemented all of the functionality that would be needed
in the web service, but you get the point.

-Tim

On Fri, Jul 8, 2011 at 4:21 AM, Geert Janssens <janssens-geert at telenet.be>wrote:

> John's suggestion to find something sql-query like to gather data might be
> nicer, as would Yawar's proposal to go for a completely declarative report.
> Both mechanisms work generically with the raw data and would adapt easily
> to
> data format changes. By the way, GnuCash comes with a query framework for
> its
> data: qof-query. It mayor may not be suitable as a basis for the first
> suggestion.
>
> I'm tempted to say here that such a generic and easy to use interface could
> be
> implemented as a later improvement, but at the same time I have a feeling
> that
> such a decision should be taken early on, because it would greatly
> influence
> how everything gets implemented.
>
> > 4. The XSLT and CSS could be very easily modified and applied not only
> > inside of GnuCash, but a user could also take the XSLT and CSS scripts,
> > modify and apply them to the exported XML reports to give it their own
> look
> > without touching the GnuCash code base at all.  For example they might
> want
> > to style a report with a company logo or different colors or other
> > graphical elements.
> > 5a. In the future, it would be possible to provide multiple different
> XSLT
> > and/or CSS styles for the reports so users could select the appearance of
> > the reports. (If someone writes additional styles)
> > 5b. In the future, it would be possible to allow users to import their
> own
> > style sheets into GnuCash and apply them to the reports. (if someone
> writes
> > the code to manage the import and style selection)
> I already some kind of a theme foundry as part of the GnuCash website,
> where
> users can add stylesheets for others to use. Something in the lines of the
> online kde/gnome theme stores
>
> Geert
>