Reporting system and potentially Python

[John Ralls]

On Jul 8, 2011, at 8:20 AM, Tim M wrote:

> 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.
> 

This is in general a good plan, but you need to know that there's a reason for the engine code to be between the storage backends and the GUI and reporting system: It's the part that knows how to manage currencies and lots and invoices and such. In database applications that's called the business logic layer. Now it's true that a lot of what is in our engine belongs in the  database layer (the backend), but there's also a lot that can't go there because databases don't know how to do it. Fixing that is another long-term project. 

Reports, the GUI, and even the command-line are called the presentation layer. The presentation layer has to pass all of its requests through the business logic layer to ensure that all of the accounting rules are applied correctly; nothing but the business logic layer should talk to the database layer. That's the theory. The reality of Gnucash is that the engine API is so confusing and inflexible that the new DBI backend has tempted people to try querying the backend directly with SQL so that they can get the reports they want without having to spend the time to learn the engine's API.

Geert mentioned the QofQuery class. I'm concerned that it's both too limited in function and too low-level (it's used by the engine to query data structures, so it may not apply business logic to its results) to work as a direct interface for a report service. It's worth studying, though, because modifying it might be the shortest path to getting a workable query interface.

Regards,
John Ralls