RFC: Move business-core objects (back) into engine, including their serialization

[Christian Stimming]

From working with the cutecash experiment I found out several facts about the 
gnucash source code structure which I'd like to present and propose here as 
they appear. Today, I'd like to discuss the business-core directory:

In gnucash, we have a bunch of "first-class objects" for the finance book-
keeping, like Account, Transaction, Split, and they are all defined inside the 
src/engine directory (with their serialization in src/backend/{xml,sql,dbi}). 
Additionally, the src/business/business-core directory defines some *more* 
first-class objects, related to business book-keeping, like Customer, Bill, 
Vendor (with their serialization in  src/business/business-core/{xml,sql}). At 
the time when this was introduced, the idea was that there might be someone 
who wants to build an application using *only* the general finance objects, 
but not the business objects.

The point is, nobody ever did this. You can see this easily: If anyone had 
ever tried this, she/he would immediately have discovered her XML files of 
gnucash cannot be read anymore as soon as she had ever entered the slightest 
piece of business objects into the XML file (or SQL database, for that 
matter). This is exactly one of the first reactions to the cutecash 
announcement: In the first few days where cutecash supported only the engine 
objects, immediately someone reported his data cannot be read [1]. As you 
might recall, we have never before ever heard such a complaint from any sub-
project there might have been. (Instead, all sub-projects that I know about 
tend to write their own XML parser, in which they of course included the 
serialization for both the engine and the business objects.)

Hence, the fact is nobody ever used this separation of the object definitions 
and their serialization, so we can conclude nobody ever needed this. Instead, 
it constantly causes us extra pain because the artifical separation of the 
first-class object definitions requires double work for many issues, and it 
increases the complexity by distributing the identical level of abstraction 
into two completely separate locations (not to mention the two different 
serializations). As it isn't needed (i.e. there isn't a requirement for this), 
we should admit this fact and get rid of it.

For this reason I propose to move all code from business-core/ into engine/, 
the code from business-core/xml/ into backend/xml, and from business-core/sql 
into backend/sql. This will get us back to the point where each single level 
of abstraction is also located in one single location in our source code.

I don't think moving this code "upstream" inside our tree might cause any 
major problems, because any "downstream" dependencies will implicitly continue 
to be fulfilled before and after the move.

Regards,

Christian

[1]
http://lists.gnucash.org/pipermail/gnucash-devel/2010-March/027718.html