What's your favorite year end method?

[Josh Sled]

Andrew Sackville-West <ajswest at mindspring.com> writes:
> I don't want to speak for jsled, but he has talked a couple of times
> about starting a next generation reporting system. He's even sketched
> in some beginning design ideas (see -devel archives). The point is to
> maintain the current reporting strucutre and keep it functioning while
> a new structure gets put in place. This is no small task.

Yup.

> I don't think anyone is married to Scheme. jsled wants to move the
> option generation back into C and then any swig-ified language can be
> used to generate reports. If I remember correctly, you are parsing the

To expand a bit more on this, the options are one place where we serialize
data not as XML or text, but as scheme expressions.  As such, we strongly
need a runtime dependency on guile to evaluate them, which makes it hard to
drop scheme as a requirement down the road.

Said another way: even if all the reports were re-written in something else
tomorrow, we'd *still* need a scheme interpreter for the one-time task to
evaluate the options at data-load time.

My thought about the sequencing here is to – in the next release that would
contain this code – get those serialized options and reports "converted" into
a more generic data-only format, then we have the freedom to change the
report implementation in any future release.

(The other option is to just say "sorry, no historical saved- or open-reports
are supported" in that hypothetical next version.   I've not ruled this out,
but I don't think it'll be incrementally more work to actually be nice about
it.)


As for the reports themselves, I don't think I want to leave it up to
"any swig-ified language", so much as have the community pick a single
preferred language, at least for the distributed set of reports.  The
motivation against leaving it open-ended is distribution-packager/maintenance
burden of depending now not on guile+slib, but on *all* of
{perl,python,ruby,haskell,guile+slib,…} for the menagerie of reports that
were contributed.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20071217/47f2abdf/attachment.bin