XML size (was: no subject)

[Paul Lussier]

In a message dated: 03 Apr 2002 10:08:34 EST
Derek Atkins said:

>Paul Lussier <plussier@mindspring.com> writes:
>
>> Has no one else here read The UNIX Philosophy?  Keep it simle, and 
>> keep it text.  If you need it to load faster, buy a faster CPU, 
>> they're cheap now-a-days :)
>
>I agree that CONFIGURATION files should be kept text.  But why data
>files?  Data files are application-specific, so why should you be
>restricted to ascii data files, especially when the data is not
>necessary human-readable in the first place?

Today that file is application specific to gnucash.  Tomorrow it may 
be shared by a contact management application like the Evolution 
contact engine, or may be accessed by a budgeting program, a Bill of 
Materials management application.  You have no idea where the future 
will lead.  Therefore, why tie yourself to an inflexible format.

>The point of moving away from XML (IMHO) is _not_ just to load faster.
>Also note that the load speed is NOT just a factor of CPU, but a
>factor of the XML implementation and overhead of processing.  It also
>takes a heck of a lot of core.

Keep in mind,  I never said that you had to stick with XML, all I 
said was that I find far more value in an ASCII text file than I do 
in a binary data format.  I don't care whether it's in XML, SGML, 
HTML, or some other format, as long as I can look at it and edit it 
with my text editor of choice in a terminal window without the 
requirement of X is all that matters.

>So, while speed is ONE goal, it is not all of it.  By using a database
>you also:
>        a) obviate the need to transaction log file
>        b) obviate the need for "backup" files

Don't databases keep transaction logs and backup files?  What happens 
when the system crashes because of a power outage in the middle of 
of a transaction?  Now you've got a corrupt binary file that contains 
all your data and it's essentially useless.

>        c) load faster
>        d) save faster

I don't see these as major advantages.  As processor speed and over 
system speed in general increase, these will decrease.  Any major 
gain in these areas now will be lost on newer hardware.

>        e) reduce the amount of core RAM required by the application
>        f) have all the code necessary to move to SQL server

So you're reducing the size of the application by adding code?
As I said previously, the average home user isn't going to have so 
much data in their file that the size is going grow to such a state 
as to impact them or the performance of their system.

I'll buy that argument for a business environment, but not for the 
home user.

>Note that I'm saying nothing about configuration files.

And neither am I.

>However, configuration != data.

Ahm, everything is data, some is just accessed and used differently or 
more often than others.
-- 

Seeya,
Paul