XML size (was: no subject)

[Jesse Becker]

--- Derek Atkins <warlord@MIT.EDU> wrote:
> Paul Lussier <plussier@mindspring.com> writes:
> 
> > I don't know how else to say this, but I LOVE THE ASCII TEXT FILE!
> > Please don't change it, at least not for the average home user.
> 
> Why does it matter to you what format it's in?  Are you actually
> LOOKING at the data file?  Using what tool?  And what do you do with
> it?  Wouldn't an "ASCII Export" be more appropriate for you?  That way
> you can easily get at the data you want.

It matters to me because while gnucash is a wonderful program, it isn't 100%
stable or bug-free yet, either in terms of features, or "doesn't crash"
(that said, I love gnucash).

A bug in Gnucash caused my entire data file to be unreadable, but I was able
to recover the file by manually editing it (with vi specifically): 
http://gnucash.org/pipermail/gnucash-user/2001-October/002807.html

Had the data been in a binary format, I would have been unable to do this,
and an 'ASCII Export' would have been of no help.

> > Performance is no everything, and once it's loaded, it's loaded and 
> > you're done waiting.
> 
> True, performance is NOT everything, but it is still important.  Sure,
> once you wait for it to load it's there, but why wait when you don't
> have to?  You do realize that even with a relatively small dataset
> your Gnucash application can rize up to the tens of megabytes of core?
> That's larger than your X server.  That kind of precludes using a
> low-end machine, doesn't it?

Funny, I haven't noticed the memory footprint increasing as much with the
size of my data file.  Granted, it gets larger, but not signifigantly so;
Using gnome certainly doens't help in this regard either.  The fact Gnucash
has such a large footprint will *only* get worse if an SQL system is used.

Additionally, parsing text files is not painful unless you have a slow hard
disk and litte RAM; if that's the case, *everything* you do is going to be
slow, not just Gnucash.

> > It's very difficult to run sed 's/Salary/Salary:Taxable/g' on a 

> Note that this will not only fail to do what you want, but could leave
> your data file unreadable and unusable.  This is _EXACTLY_ the kind of
> thing that we DON'T want people to be doing!  If you want to change

And it's *EXACTLY* what you need to do if the application is what botches
the program in the first place.  I do not regularly edit my data fails
because I don't need to, but I sure am glad that I *can* when I *do* (after
much research in determining the minimum amount change needed).

> Also, with an _embedded_ SQL server (which is what I'm talking about)
> there is no startup time.  There is no separate SQL database process.

It's more code that needs to be executed, ergo a longer startup time.  By
the same token, a parser for an ASCII/XML file also takes time to run, but
I'd guess it's less that is needed to load a database parser.


--Jesse

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/