Beyond 2.8 - some design thoughts

[Geert Janssens]

Op woensdag 27 december 2017 12:51:32 CET schreef Wm via gnucash-devel:
> On 24/12/2017 16:34, Geert Janssens wrote:
> 
> [snips below, hopefully context maintained]
> 
> > 1. Use of namespaces.
> > 
> > For 2.8 I have been working on converting parts of the CSV importer to
> > C++.
> > And considering the class structure that is slowly forming there (still in
> > flux as conversion of additional importers reveals design limitations that
> > shouldn't be there) I am even tempted to use nested namespaces there (not
> > nested classes, mind you) like
> > 
> > On the other hand I don't have much experience with namespaces yet (other
> > than using st:: and boost:: which have nested namespaces as well) so I
> > don't know the pro's and con's of it. So I'm interested in opinions about
> > this.
> I'm not sure what most people consider CSV accounting data is useful to
> begin with, although I also know it can't be ignored entirely.
> 
> The ever-improvement of the csv import is a project that will always
> fail, it happens every time someone exports a csv file from their
> accounting program / spreadsheet and the gnc import doesn't say "hooray,
> I love your format, we bow to your format". 

Whether it's a useful format or not is not too important. It is pretty 
universal though and a generic  export format available in many accounting 
packages, including online banking sites. For that reason alone we have to 
support it.

It comes in many variations though so it is likely some tweaking will always 
be necessary. What I aimed for in the new csv importer is to make fewer 
assumptions on what the exact format of a csv file is. The importer is now 
configurable with live preview.

I agree we'll probably never be able to support all exotic flavors of the csv 
format. But if I can tip the balance from 80% of the users has to preprocess 
their csv file to 20% have to, that's a win for gnucash in my opinion.

> I suggest a presumed import
> format of ledger-cli type data and levering the work of shared open
> source accounting data.  Writing a script to get from a csv into
> ledger-cli is transparent, portable and useful to a broad community.
> 
A ledger-cli type data import would surely be welcome.

On the other hand not all of our users would be capable of writing such a 
script. It would shift the burden of getting the tweak the csv file for 
usefulness one level up, namely to get it to convert into ledger-cli format. 
So there also each possible variation has to be taken into account. So in the 
end I don't see how this would make things easier for the end user.

> > 2. Versioning.
> > 
> > The migration to gtk2 has been a long
> > time ago and the software world has evolved since then. Release cycles in
> > general have shortened. Incremental changes are usually preferred over big
> > bang changes. So I think our numbering scheme is in for a modernization.
> 
> gnc's versioning does seem dated although I expect people that read the
> dev list may be used to them by now.
> 
> As someone less involved in gnc coding but with a lot of interest in
> data I'd have thought the next non-backward compatible format change
> would be the next gigantic.

Ok, which is more or less what my proposal achieves.

Geert