Reporting system and potentially Python

[John Ralls]

On Jul 8, 2011, at 1:25 PM, Tim M wrote:

> On Fri, Jul 8, 2011 at 10:28 AM, John Ralls <jralls at ceridwen.us> wrote:
> 
>>>> I think it could be implemented as just another interface to the data such as we have XML and DBI currently
> Those are the database or storage layer interfaces that engine uses for persistence, not interfaces that presentation layer code should use.
> 
> 
> That was in relation to if someone were to (in the long distant future) add to the web service so that it provides more or less the entire GnuCash functionality via the web service.  Then you could have a client-server setup where one instance of GnuCash runs on a central machine acting as the GnuCash server, and other remote machines connect to the server as clients.  The clients would need to read and write data from the central server, hence why I suggested the requests to the central server could be implemented as just another data interface.  Currently XML and databases are allowed, another interface could be added for SOAP/REST, which would pull the data from the central GnuCash server.
> 
> This is just a potential use case of a greatly enhanced web service which could theoretically be provided by GnuCash, and goes well beyond the needs for the basic reporting infrastructure.  I do not have any plans to implement it, I was just making the point that it would be theoretically possible to enhance the basic web service functionality to achieve a server/client access method, as well as for users to write their own third-party applications which could read/write data into the GnuCash database via the web service, such as a web page where users enter their expense transactions.  The benefit of this is multiuser access - and also a business could provide their own web interface or standalone application for users to enter expenses or other txns, while restricting the user's access from any other functionality of GnuCash because they do not have direct access to the GnuCash interface and/or GnuCash data files.
>  
> My concern with WSDL is that each Scheme report is a function which calls engine functions. There's no generalized query language or query interface AFAICT. I don't know anything about building a WSDL, but if it's like other query languages (e.g. SQL) it seems likely to me that there will be a pretty bad impedance mismatch in some areas. 
> 
> 
> WSDL is not a query language.  WSDL is Web Service Definition Language.  Basically a WSDL is an XML file which defines functions that a web service exposes.  The WSDL describes how to call the web service's functions, what variables it accepts (or requires) and if the web service returns any information, the WSDL describes what information the client can expect the web service to return.  It is basically a web-based API definition.
> 
> So the WSDL does not provide any actual code - it simply describes the web service.  The actual code which executes any incoming requests sits inside the web service application.
>  
> Also, as you've laid out the flow, it seems a bit heavyweight for the internal report generator.
> 
> Indeed, it is heavyweight but on the other hand it would add a lot of flexibility to the reporting system.
>  
> Rather than having to format an http request and setting up an IP listener in Gnucash (and consequent (x)inetd setup), wouldn't a socket interface that both the Report subsystem and the web server connect to?
>  
> 
> I am not familiar enough with what the actual networking implementation would require, so it will probably be a discovery process while writing the new reporting code to see what is the best option is, unless someone else steps in to code the network/socket interface for me (any takers? :oD ).  As long as the interface meets the basic requirement of being able to communicate messages between the reporting system and GnuCash, then whatever communication method is used should be sufficient.
>  
> Simplifying the report side further, once we have the code to handle general query strings and return XML, that interface can pretty easily be provided both as an API (returning a DOM tree to save writing/parsing overhead) and a socket interface for a SOAP/REST server -- or anything else we dream up later -- to connect to.
> 
> I think the best approach might be to work backwards by defining the WSDL based on the existing reports and determining what functions would need to be exposed to retrieve the data required to generate those reports.  Once a draft of the WSDL is accepted, the web service can be written to provide the functionality defined by the WSDL.  After or concurrently with that, the individual reports could be written and tested against the web services.  As the web services are completed, the reports should generate successfully.
> 
> Later, if new functionality is needed for the reporting system, then it can be defined in a new version of the WSDL and exposed by the web service.
> 
> Does this make sense?

Starting with the WSDL (or some pseudocode equivalent) is fine, it's basically documentation at this point. 

But rather than diving in with a web service next, write the functions that the web server would call to extract the data and build the DOM tree (you can use SAX to create the DOM-document if that's easier). With that in hand we can figure out the easiest way for the report code to submit the request and get the DOM document back for xslt to format the report. 

Regards,
John Ralls