XML size

[Rob Browning]

"Robert A. Uhl" <ruhl@4dv.net> writes:

> That's purely an in-application data representation issue.  The file
> itself is or should be loaded into memory essentially a line at a
> time--the only stuff that should stay in memory is the actual data
> representation.

In theory, yes, but at least when I first started working on it,
libxml couldn't easily parse for loading incrementally, though I did
that initially, and it couldn't write incrementally at all -- you had
to build an xml tree with *all* your data and then call "dump" :<

> Note that I too am against XML.  It's inherently slow (and _is_ to
> blame for some of the slow load of current versions) and overly
> verbose.  It takes up too much space.  Far, far better IMHO would be
> Scheme forms.  This would also allow one to do some interesting
> guile-fu and do things like:

You and me both :> We actually talked about this quite a bit when XML
was undertaken.  Though I still like scheme forms, I'm now convinced
that for gnucash, SQL is probably a better route, and then given
guile-pg (or another suitable interface to postgresql) you can do
anything you want from guile.

> And get a useful datum.  But then, I'd like to be able to write normal
> guile code which includes GnuCash's transaction model.  Maybe I can
> anyway, and just don't know it.

You can, but it's not as convenient right now as it could be, and the
documentation for how to do it is not very rich.

> I really do think that Scheme special forms/macros are the way to go.

FWIW I'd rather see SQL with scheme forms as a supported import/export
format.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD