XML size (was: no subject)
Thu, 04 Apr 2002 00:32:43 -0500
In a message dated: 03 Apr 2002 21:09:08 EST
Derek Atkins said:
>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.
Oh, okay. I've had no problems, so I guess I should count myself lucky.
>It is quite possible to write out an XML file that another version of
>Gnucash can't read or, worse, can only partially read.
I'll agree, that's a bad thing. I'm still using 1.6.4, and it's
worked flawlessly for me since I moved to it. I haven't seen the
need to upgrade to anything else yet (sounds like maybe I shouldn't?)
>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.
Well, yeah, but that's the nature of text vs. binary in general, is
it not? I'll agree that XML is ugly, and overly verbose, and maybe
the files are larger than they should be, but you do expect some
bloat with the move from binary to ascii, don't you?
>Moreover, the data files SHOULD NOT be accessed directly by users or
>other applications... They should use the Gnucash API.
Well I don't completely agree. I would agree that if accessing the
data via another application, that application should use the Gnucash
API. As for being directly accessed by the user, sometimes the user
needs to because the user has no other choice. Ascii just makes it
more easily possible than a binary format. I would also contend that
the "average" user I'm so fond of championing for is not overly
likely to muck with the data file in general. Of course, if they
discover it's a normal ascii text file, they are probably more likely
to do so than if it weren't. And if they screw something up, then
it's their own fault for mucking where they shouldn't.
>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
Now that understand you are talking about an embedded database (with
import/export features), I agree.
>I'm sorry you feel so strongly about this.
I'm not. I've got feel strongly for something :)
It's just too bad I was feeling strongly for something which was
completely misguided. Seems I mis-interpreted as much as I accused
Chris Lyttle of. I am truly sorry. for all the wasted bandwidth,
for the argumentative posturing, for not more clearly reading
what was written, and for assuming I had then accusing Chris of doing
what I myself was guilty of.
> I'm glad that you like Gnucash so much. Perhaps what we need to
> do is implement the feature that you need so you don't need to
> edit the data files by hand.
I love GnuCash. If I didn't, I wouldn't have argued so vocally to
keep what I thought was a great system in place for what appeared to
be something I didn't think gained anyone anything. I also wouldn't
have stuck around here for the last 5+ years testing, debugging,
providing feed back etc. I truly appreciate this great application,
and really wish I had the talent you all have so that I could at
least contribute to it somehow!
As for features, there really aren't a lot features I need.
Here are some of the benefits I've enjoyed under the ascii-text format
though, which I've found extremely useful:
- the ability to check in/out of rcs
this gives me the ability to associate comments
with a particular data entry session as well as
the ability to check out a "view" of my data as it
was at a particular time in the past.
- the ability to 'grep' things like dates, check numbers,
descriptions/memos, and the like from the file without
having to fire up the actual application; especially when
connected to my system over a slow dial up link.
- the ability to easily change various fields with a global
search/replace like sed when I realize I need to change
something which has mistakenly been propagated throughout
There are probably more, but these are the ones I can think of off
the top of my head. Though I would like to point out, that by
providing an import/export feature would still allow me to do any of
the above with out a lot of effort (provided I did not need to fire
up the gui to do so).