Re: build check failure: POTFILES references non-existing gnc-pricedb-static.c?
On donderdag 7 juli 2011, Derek Atkins wrote: Hey, I just tried to build a clean build from a clean checkout of trunk on a fresh Fedora-15 system. In addition to two bugs I just filed I also ran into another issue in make check on trunk: make[1]: Entering directory `/home/warlord/src/gnucash/gnucash-svk/build/po' make[1]: *** No rule to make target `../src/engine/gnc-pricedb-static.c', needed by `gnucash.pot'. Stop. make[1]: Leaving directory `/home/warlord/src/gnucash/gnucash-svk/build/po' make: *** [check-recursive] Error 1 I cannot find gnc-pricedb-static.c in the sources, but it does appear to be in POTFILES.in? Was this an oversight? POTFILES.in was last modified on May 31st: r20723: gjanssens | 2011-05-31 09:07:30 -0400 -derek Oops, that is indeed a file that slipped in by accident. I'll remove it later today. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
On donderdag 7 juli 2011, SASAKI Suguru wrote: Hi, No one seems to be intereted in this, but No, no, I am interested, but I didn't have the time yet to respond. I'll see if I can pull your build system tweaks and merge them in the main repository. I personally like the possibility to generate more available formats. I have pushed some tweakes in build system and push to https://github.com/sss/gnucash-docs/tree/2.4.1-in-epub-and-mobi , and you can downloadn .epub / .mobi from https://github.com/sss/gnucash-docs/downloads . Thanks, Thanks for your work on this! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On vrijdag 8 juli 2011, Tim M wrote: What I'm looking for is this: Separate the act of actually gathering the data from the GnuCash database from transforming it for display, so that the output can be made much more interactive and easy to style and make 'pretty' :). Use a well known programming language to aggregate the data to make it easier to create new reports which output different sets of data. I've thought about this a little bit, and here is what I am thinking. Let me know if this sounds un/reasonable or just plain incorrect. (Note that I am basing this off of not being familiar yet with how the current scheme architecture actually manages pulling the data out of gnucash, so please correct me where I am wrong or point out the significant flaws) 1. Create the 'new' reporting system alongside the existing one so that the reports do not suffer until the existing functionality can be fully replaced by the new system. After all reports are replaced and working, the old scheme code could be pulled. 2. Create a set of libraries and/or use the existing gnucash libraries for querying information from the database. Based on the discussion, I presume C or Objective C would be best and just avoid Python/Scheme altogether (I am not sure how the scheme system actually performs the data queries right now). If all the necessary code is already in place, then this does not require any work. 3. Using these libraries, create the code for aggregating the data (also in C or Objective C) for each report. A single prototype report would be OK to start. Output the report data as structured XML. The XML data should adhere to an XML schema. 4. For each report, create an XSLT file which will transform the data into HTML/XHTML for display. 5. A small amount of javascript would be needed to perform the actual XSLT transformation but it would be pretty small. 6. Style the page elements using CSS. Also, I think the jqplot patch that has been made could be migrated in to the new reporting system, as those graphs look really nice. I think there are several benefits to this approach: 1. Currently reports can only be exported as HTML. By making the reporting code export an XML data structure, reports could be easily exported from GnuCash as XML (pre-transformation) or as HTML (post-transformation). 2. Anyone could write their own XSLT transformation file to display the data differently. Like pdf, using the fop transformer. An improvement that would also be greatly appreciated by users of the business features. We have already some experience with this transform in the gnucash-docs, so it would not be too difficult to apply that experience on the reports. So me too I like your ideas of starting with xml and the separation into XSLT, CSS and friends. 3. The actual XSLT, HTML, and CSS code would be very easy to read and modify by anyone familiar with it. The backend reports would still be in C/Objective C for compiling the data and as such require some coding knowledge, but it would be much easier to start using than the existing scheme code. This part is not clear to me. Do you mean that if Joe user wants to add a new report, he will have to write some C code, like for example to add a new data query ? I guess that would limit the extendability of the reports equally to having them in scheme. John's suggestion to find something sql-query like to gather data might be nicer, as would Yawar's proposal to go for a completely declarative report. Both mechanisms work generically with the raw data and would adapt easily to data format changes. By the way, GnuCash comes with a query framework for its data: qof-query. It mayor may not be suitable as a basis for the first suggestion. I'm tempted to say here that such a generic and easy to use interface could be implemented as a later improvement, but at the same time I have a feeling that such a decision should be taken early on, because it would greatly influence how everything gets implemented. 4. The XSLT and CSS could be very easily modified and applied not only inside of GnuCash, but a user could also take the XSLT and CSS scripts, modify and apply them to the exported XML reports to give it their own look without touching the GnuCash code base at all. For example they might want to style a report with a company logo or different colors or other graphical elements. 5a. In the future, it would be possible to provide multiple different XSLT and/or CSS styles for the reports so users could select the appearance of the reports. (If someone writes additional styles) 5b. In the future, it would be possible to allow users to import their own style sheets into GnuCash and apply them to the reports. (if someone writes the code to manage the import and style selection) I already some kind of a theme foundry as part of the GnuCash website, where users can add stylesheets for others to use. Something
Re: build check failure: POTFILES references non-existing gnc-pricedb-static.c?
On donderdag 7 juli 2011, Derek Atkins wrote: Hey, I just tried to build a clean build from a clean checkout of trunk on a fresh Fedora-15 system. In addition to two bugs I just filed I also ran into another issue in make check on trunk: make[1]: Entering directory `/home/warlord/src/gnucash/gnucash-svk/build/po' make[1]: *** No rule to make target `../src/engine/gnc-pricedb-static.c', needed by `gnucash.pot'. Stop. make[1]: Leaving directory `/home/warlord/src/gnucash/gnucash-svk/build/po' make: *** [check-recursive] Error 1 I cannot find gnc-pricedb-static.c in the sources, but it does appear to be in POTFILES.in? Was this an oversight? POTFILES.in was last modified on May 31st: r20723: gjanssens | 2011-05-31 09:07:30 -0400 -derek This has been fixed now. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
On vrijdag 8 juli 2011, Geert Janssens wrote: On donderdag 7 juli 2011, SASAKI Suguru wrote: Hi, No one seems to be intereted in this, but No, no, I am interested, but I didn't have the time yet to respond. I'll see if I can pull your build system tweaks and merge them in the main repository. I personally like the possibility to generate more available formats. I have pushed some tweakes in build system and push to https://github.com/sss/gnucash-docs/tree/2.4.1-in-epub-and-mobi , and you can downloadn .epub / .mobi from https://github.com/sss/gnucash-docs/downloads . Thanks, Thanks for your work on this! Ok, I have taken a closer look your your tweaks. I have a few questions: 1. I notice you use a ruby script to convert to epub. Why did you choose that instead of the standard docbook xsl transformation ? The epub stylesheet is not part of our repository because we never used it before, but it can be added easily. 2. The mobi format appears to be created using a conversion tool that is shipped with calibre on my Fedora system. This is fine in itself, but it would be useful if you could add a note about this in the README file. That would help people that want to generate mobi formatted documentation. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
Hi, Thanks for reviewing. 2011-07-08 Geert Janssens janssens-ge...@telenet.be: Ok, I have taken a closer look your your tweaks. I have a few questions: 1. I notice you use a ruby script to convert to epub. Why did you choose that instead of the standard docbook xsl transformation ? The epub stylesheet is not part of our repository because we never used it before, but it can be added easily. I know that we can convert DocBook to XHTML with standard XSLT, and then convert XHTML to EPUB with somthing like calbre. This Ruby script came from DocBook project(, and packaged as dbtoepub in Debian (sid)). README about this script at URL:http://docbook.sourceforge.net/release/xsl/current/epub/README says, | These are XSL stylesheets for transforming DocBook XML document | instances into .epub format. | [...] | An alpha-quality reference implementation (dbtoepub) for a DocBook to .epub | converter (written in Ruby) is available under bin/. They say these scripts and XSL stylesheets are alpha-quality, but I think this is somewhat specialized for EPUB generation and we can get better results with these than going through DocBook - XHTML - EPUB on our own. 2. The mobi format appears to be created using a conversion tool that is shipped with calibre on my Fedora system. This is fine in itself, but it would be useful if you could add a note about this in the README file. That would help people that want to generate mobi formatted documentation. Exactly. We need some notes in README and some tweak in spec file for packaging. I'll work on that. Best regards, -- SASAKI Suguru mailto:sss.so...@gmail.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
I've misread one point. Ok, I have taken a closer look your your tweaks. I have a few questions: 1. I notice you use a ruby script to convert to epub. Why did you choose that instead of the standard docbook xsl transformation ? The epub stylesheet is not part of our repository because we never used it before, but it can be added easily. Right. If we'll merge stylesheets for EPUB into gnucash-doc repository, this Ruby script is not necessary, I guess. I'll investigate it as well. Regards, -- SASAKI Suguru mailto:sss.so...@gmail.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Invoice Importer
On Monday 13 Jun 2011 01:31:48 knew two gnucash wrote: It didn't like the permissions the 1st round - said it could not open the file. Solved that with some chmod + action and got: woop /usr/local/share/gnucash/python Hello from python! Entries for test, test2 and test3 show up that did not when the error was 'can't open file' Alas, I do not see a change in the menus. So - what am I missing? Sorry for the delayed reply I've not been monitoring the list lately. You have edit your config.user file to enable the module. Add the line: (gnc:module-load gnucash/plugins/bi_import 0) to it. On linux this file is in $HOME/.gnucash -- GPG Key: 1024D/050895C2 Keyserver: http://pgp.mit.edu/ Search String: 0x050895C2 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Fri, Jul 8, 2011 at 8:44 AM, John Ralls jra...@ceridwen.us wrote: 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 John, Thank you for the clarification. I think we are on the same page. Any sort of web service would act just as an interface to the outside (the Report system, or other third-party requests to the GnuCash web service) and then internally it would perform queries against the GnuCash DB via the engine code. I never had any intention of querying the DB directly - I only intended to wrap the engine code (whether it be QofQuery or whatever else is appropriate). The web service methods would only call the necessary engine code to query the data, and then wrap the results into the XML output and send it back to the client. Are you saying that it may be a problem to implement a web service to query the database using the engine code to generate the reports this way? Isn't this what the scheme reports do now? Otherwise how do they access the data to generate the reports? I presume they do not access the DB directly but use the engine code to do it. As I see it, the web service should work more or less as follows: 1. A Report or other service issues a SOAP/REST request to the GnuCash web service. The request must adhere to the GnuCash WSDL (anything not adhering to it will be ignored). 2. The GnuCash web service receives the request. 3. The web service queries the database using the GnuCash engine code. 4. The web service wraps the results from the engine code into an XML wrapper. 5. The web service sends the XML output back to the client. 6. The XSLT translation occurs on the client to display the data. Thanks, -Tim ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Jul 8, 2011, at 10:24 AM, Tim M wrote: On Fri, Jul 8, 2011 at 8:44 AM, John Ralls jra...@ceridwen.us wrote: 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 John, Thank you for the clarification. I think we are on the same page. Any sort of web service would act just as an interface to the outside (the Report system, or other third-party requests to the GnuCash web service) and then internally it would perform queries against the GnuCash DB via the engine code. I never had any intention of querying the DB directly - I only intended to wrap the engine code (whether it be QofQuery or whatever else is appropriate). The web service methods would only call the necessary engine code to query the data, and then wrap the results into the XML output and send it back to the client. Are you saying that it may be a problem to implement a web service to query the database using the engine code to generate the reports this way? Isn't this what the scheme reports do now? Otherwise how do they access the data to generate the reports? I presume they do not access the DB directly but use the engine code to do it. As I see it, the web service should work more or less as follows: 1. A Report or other service issues a SOAP/REST request to the GnuCash web service. The request must adhere to the GnuCash WSDL (anything not adhering to it will be ignored). 2. The GnuCash web service receives the request. 3. The web service queries the database using the GnuCash engine code. 4. The web service wraps the results from the engine code into an XML wrapper. 5. The web service sends the XML output back to the client. 6. The XSLT translation occurs on the client to display the data. Tim, You confused me with the line 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. 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. Also, as you've laid out the flow, it seems a bit heavyweight for the internal report generator. 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? 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
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. 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 ___ gnucash-devel mailing list
Re: GnuCash features webpage
In the last couple of days I've made some modifications to the GnuCash website. You can see the result in the beta website [1]. In particular I've modified the main page and the features page. The latter is not yet completed (suggestion for content are welcome!). I ask if someone could test this page with a different browser looking for strange behaviors (I've only used ff 3.6 and ff 5 and it looks as it should). Thanks Cristian [1] http://www.gnucash.org/beta/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
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
Re: Reporting system and potentially Python
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
Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
2011/7/9 Geert Janssens janssens-ge...@telenet.be: I wonder if this script is required to generate the epub format, or if it's just a wrapper around a generic xslt transformation. From a quick view with this script, this script does: - XSLT transformation using xsltproc - zip these reesults into .epub So, basically, we can go whitout this script. 2011/7/9 Geert Janssens janssens-ge...@telenet.be: While googling, I found this: http://www.ibm.com/developerworks/xml/tutorials/x-epubtut/section5.html It is basically the recipe to create an epub file from the docbook source. Looking at it, it seems to consist of - one xslt transform using the epub xsl from docbook - generating a proper zip file with mimetype included At first sight this doesn't seem to be too difficult to transform in a makefile ruleset. We may be able to avoid a ruby dependency in this way. Yes, in .epub generation, we can avoid a dependency on Ruby in such a way. But in .mobi generation we *can't avoid* a dependency on calibre (and thus on Python). So if we merge *only .epub generation* into build system, I'll investigate a way to go wihtout such a script (and thus Ruby), but if we merge *.mobi generation as well*, we can rely on Pyhon and writing dbtoepub in Python is sufficeient. Minimizing the dependencies are a good way to go, but we are not neacessarily stoic about using other tools. I guess, Python is almost a standard tool on Linux and other enverionments, so depending on Python is not bad. -- SASAKI Suguru mailto:sss.so...@gmail.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
Folks, On 2011-07-08, at 01:15, Yawar Amin wrote: […] I like the idea of XML - HTML + CSS + JavaScript plots. How about moving to a completely declarative XML report, where we use XML tags to ask for things like account names and balances, and using the Scheme (or […] I got to thinking that Scheme itself can be used as a declarative,* domain-specific language for defining GnuCash reports. We could have a declarative API that sits on top of the currently-existing report API, and abstracts away the complexities of writing out an HTML page and building a report options dialog box. Sort of like LaTeX hides the raw TeX complexities of laying out a page. Here’s my income statement converted over from XML into (declarative) Scheme: (report income-statement (defs (def-date start-date General/Start date 2011-01-01) (def-date end-date General/End date 2011-07-31) (def-label title General/Report title Income Statement) (def-label subtitle General/Report subtitle '((string (date start-date)) to (string (date end-date (def-account-group income Accounts/Income accounts '(3288757aa761c7bba993766bfb433466 e49c976843a1dba40570ed6295e89a33)) (def-account-group expenses Accounts/Expense accounts '(df72fb29f46e90e12c2ba10d582a6148 e518845492b7b9cfa614cc405a8cf715)) (def-account net-profit-loss Net Profit (Loss) (subtract (balance (account-group income)) (balance (account-group expenses) (title (label title)) (subtitle (label subtitle)) (filter-date (date start-date) (date end-date”) (group-date 'month (tabular (account-group income) (account-group expenses) (account net-profit-loss) And here’s the report structure in plain language: report definitions (can double as options for the report options dialog box) definition of date (start date) definition of date (end date) definition of label (report title) definition of label (report subtitle) definition of account group (income) definition of account group (expenses) definition of a calculated account (net profit or loss = income - expenses) report title report subtitle filter by date (only include transactions within date range) group by date (monthly–this should show balances in the table as one column per month) tabular display (we could also provide a graphical display–i.e. column chart) account group (income) account group (expenses) account (net profit or loss) What I’m trying to express here is that a tabular layout should know how to display accounts and groups of accounts: put the account name on the left and the balance on the right. And that the report engine should know how to re-use the definitions of account groups, labels, and dates to build up the options dialog box. We can help it along a little, e.g. in the call to (def-date start-date General/Start date 2011-01-01) you see that the second argument is a string that provides the tab the widget should be placed in (“General”) and widget’s label for the dialog box (“Start date”), separated by a slash. Oh, and since it’s a def-date, the option widget should be a date picker. This functionality can all be behind the scenes, leaving the report developer to just declare what his/her report should contain. Note that in the call to (def-account net-profit-loss Net Profit (Loss) …) the second argument is an empty string, meaning don’t place this as a widget in the options dialog box. If we stick with Scheme, we can take advantage of all the low-level functions that already exist for data extraction and report layout. But we can also move to a declarative model where we can have convention (re-use the report definitions as options) over configuration (build an options dialog box). Also, is it still true that we have to restart GnuCash every time we change a Scheme report, to see the changes? In any case, we need to make it dead easy for users to import and run and custom reports. Best, Yawar * I find that I’m saying ‘declarative’ a lot nowadays–I think it has to do with the fact that I’m learning Haskell :-) PGP.sig Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Jul 8, 2011, at 8:15 PM, Yawar Amin wrote: Folks, On 2011-07-08, at 01:15, Yawar Amin wrote: […] I like the idea of XML - HTML + CSS + JavaScript plots. How about moving to a completely declarative XML report, where we use XML tags to ask for things like account names and balances, and using the Scheme (or […] I got to thinking that Scheme itself can be used as a declarative,* domain-specific language for defining GnuCash reports. We could have a declarative API that sits on top of the currently-existing report API, and abstracts away the complexities of writing out an HTML page and building a report options dialog box. Sort of like LaTeX hides the raw TeX complexities of laying out a page. Here’s my income statement converted over from XML into (declarative) Scheme: (report income-statement (defs (def-date start-date General/Start date 2011-01-01) (def-date end-date General/End date 2011-07-31) (def-label title General/Report title Income Statement) (def-label subtitle General/Report subtitle '((string (date start-date)) to (string (date end-date (def-account-group income Accounts/Income accounts '(3288757aa761c7bba993766bfb433466 e49c976843a1dba40570ed6295e89a33)) (def-account-group expenses Accounts/Expense accounts '(df72fb29f46e90e12c2ba10d582a6148 e518845492b7b9cfa614cc405a8cf715)) (def-account net-profit-loss Net Profit (Loss) (subtract (balance (account-group income)) (balance (account-group expenses) (title (label title)) (subtitle (label subtitle)) (filter-date (date start-date) (date end-date”) (group-date 'month (tabular (account-group income) (account-group expenses) (account net-profit-loss) And here’s the report structure in plain language: report definitions (can double as options for the report options dialog box) definition of date (start date) definition of date (end date) definition of label (report title) definition of label (report subtitle) definition of account group (income) definition of account group (expenses) definition of a calculated account (net profit or loss = income - expenses) report title report subtitle filter by date (only include transactions within date range) group by date (monthly–this should show balances in the table as one column per month) tabular display (we could also provide a graphical display–i.e. column chart) account group (income) account group (expenses) account (net profit or loss) What I’m trying to express here is that a tabular layout should know how to display accounts and groups of accounts: put the account name on the left and the balance on the right. And that the report engine should know how to re-use the definitions of account groups, labels, and dates to build up the options dialog box. We can help it along a little, e.g. in the call to (def-date start-date General/Start date 2011-01-01) you see that the second argument is a string that provides the tab the widget should be placed in (“General”) and widget’s label for the dialog box (“Start date”), separated by a slash. Oh, and since it’s a def-date, the option widget should be a date picker. This functionality can all be behind the scenes, leaving the report developer to just declare what his/her report should contain. Note that in the call to (def-account net-profit-loss Net Profit (Loss) …) the second argument is an empty string, meaning don’t place this as a widget in the options dialog box. If we stick with Scheme, we can take advantage of all the low-level functions that already exist for data extraction and report layout. But we can also move to a declarative model where we can have convention (re-use the report definitions as options) over configuration (build an options dialog box). Also, is it still true that we have to restart GnuCash every time we change a Scheme report, to see the changes? In any case, we need to make it dead easy for users to import and run and custom reports. Best, Yawar * I find that I’m saying ‘declarative’ a lot nowadays–I think it has to do with the fact that I’m learning Haskell :-) Fun. Two questions: Can that be easily converted into a string parser so that normal users aren't put off by the extra parentheses, and is there anything about that that works in Scheme but not in C? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
