XML size (was: no subject)

[Derek Atkins]

Paul Lussier <plussier@mindspring.com> writes:

> Everything stated so far has been essentially that it would be
> "easier to program it this way".  That, IMO, is not a valid reason 
> for changing it, at least not at this point.  There are more 
> important things which need attention, like incorporating major 
> feature sets.  Don't fix what ain't broke.  It's ugly, but it's not 
> broken.

Actually, it is broke.  There are some backwards compatibility
problems in the XML code.  There are also for forwards-compatibility
problems in the XML code, too.  It is quite possible to write
out an XML file that another version of Gnucash can't read or, worse,
can only partially read.

The XML datafiles are an order of magnitude larger than they need to
be, and are certainly an order of magnitude larger than the old binary
format.  XML is overly verbose.  Moreover, the data files SHOULD NOT
be accessed directly by users or other applications...  They should
use the Gnucash API.

Moving to SQL not only simplifies the programming, it allows us to
write a simple API for other applications to access Gnucash data
files.  It scales.  It will be faster.  It will give a better user
experience to the vast majority of users (you are clearly the
exception).

I'm sorry you feel so strongly about this.  I'm glad that you like
Gnucash so much.  Perhaps what we need to do is implement the features
that you need so you don't need to edit the data files by hand.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available