Reporting system and potentially Python

[Tim M]

Agreed. That sounds like a good plan.

-Tim

On Fri, Jul 8, 2011 at 4:54 PM, John Ralls <jralls at ceridwen.us> wrote:

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