I've seen several references here to the policy direction that SQL
(-lite or my-, or otherwise) will be the future preferred datastore.
Associated with these, there are discussions that the future of
reporting interfaces will likely be through some flavor of reporting
tool founded on the SQL interfaces.
There are FAQ entries which discourage SQL backend uses for most users.
I've got an itch I'd really like to scratch: now that I'm
programmatically submitting payments through the python API, the major
time sink and source of error in my duties as Hackerspace treasurer are
in clicking through the "generate a customer report for _this_ one",
"generate a report for _that_ one".
If there's interest, I'd be interested in trying to build that report,
and others as I come to grasp them, with a reporting infrastructure
acceptable to the GnuCash devs. I think I've already got a FSF
assignment in place. (though you don't mention that in your
contribution FAQ page)..
So much for background; a few concrete questions:
+ Have the GnuCash devs discussed any reporting infrastructure or
frameworks which they would find preferable, or unacceptable?
+ Are there any abstract reporting infrastructure characteristics that
can be easily named in advance? ("multi-platform" is the obvious start
of that list...) Any language-environment desires?
+ I see that the Reports part of the Wishlist specifically mentions
possibly using Python; but recently in the mailing list, I read that
the Python APIs aren't functioning on Windows, which makes me wonder if
the wishlist is very far ahead of the currently achievable state?
+ I see conversation about 'clickable' reports, and the wishlist
specifically mentions Javascript in the context of the Gnucash report
screen. How strong is that desire?
Thank you for considering my message.
- Allen S. Rout
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
