Agreed. That sounds like a good plan. -Tim
On Fri, Jul 8, 2011 at 4:54 PM, John Ralls <jra...@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 <jra...@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 > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
