Reporting system and potentially Python

[Tim M]

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.
>
> Regards,
> John Ralls
>
>
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?

Thanks,
-Tim