XML size (was: no subject)

[Paul Lussier]

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
>exception).

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
	  the file.

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).

Thanks!
-- 

Seeya,
Paul